Newsletters
Abstract
The ICFM data model is customized to allow fraud to be detected within and across business domains. The data model represents a hybrid data store that employs an approach that combines a prescriptive data schema with a corresponding set of generic data objects. This provides a rich data model that has the flexibility to span silos and industries.
Content
The ICFM data model is also designed to aid in finding fraud, but (sometimes) at the expense of good object or attribute names that are industry-specific. For instance, ICFM supports an object that is called an "account", which makes sense in a financial industry, but that same object would be known as a 'policy' in the insurance industry.
For any domain (for example, banking and insurance), there are a set of objects that provide immediate business understanding. These business objects, also known as logical objects, represent a specific object and generally have an expected set of related attributes, such as a person's name, address, banking accounts and balances for each, or a person's name, address, insurance policies, and the cash value for each. Grouping attributes together based on a specific business domain usually requires you to create an ICFM business object that groups these attributes together.
There is a growing number of business objects that can be used instead of creating a new one. For instance, in the insurance space, there are business objects that define the attributes for medical providers, invoices, loss events, line item procedures, diagnosis, loss exposures, vehicles, and other common objects. Where possible, use these common objects. If not used directly, they provide guidance on how these business level objects map into the ICFM database, which is optimized for fraud detection.
In the creation of a new business object, the starting point is one of the primary ICFM objects. Use the following guidelines to determine how to make the right decisions on the underlying ICFM objects and attributes.
- The ICFM object PARTY relates to individuals and organizations, including their address, phone numbers, emails, driver license, tax ID, or other identifying attributes.
- An ACCOUNT in ICFM terminology refers to the details about a specific "digital account" that is primarily used for financial transactions; such as a banking account, insurance policy (account), or online 'store' account. In each of these examples, the ICFM ACCOUNT object contains details about that account, party associations to that account (such as owner and user roles to the account), and all transactions that use that account. Thus, an ACCOUNT object would be used for any data pertaining to "an agreement between a user and the provider of a set of services".
- In ICFM, TRANSACTION and EVENT objects are similar. One simple difference between them is that an event happens in time and space while a transaction happens between two accounts (or the parties that own those accounts). This means that if a (new) business object needs to have details on location, for instance the location of an accident, this would be expressed as an EVENT object in ICFM. Whereas, an invoice or bill is something that happens between two parties, or to be more exact, it is between the accounts that are controlled by those parties, hence a TRANSACTION in ICFM. Another distinction is that a TRANSACTION has monetary values, such as a bank transfer or withdrawal amounts, or an insurance invoice containing cost of treatments; whereas an EVENT does not.
- Two other common objects in ICFM are GROUPs and PHYSICAL OBJECTs, which are using to associate objects into a common "group," such as customers or "cars available for sale." The physical object data type can refer to concrete objects, such as a car, truck, house, or building, as well as more logical things, such as an IP or an ANI port (phone jack port). When you define a business object, attempt to use the structured fields as much as possible. For instance, an ICFM TRANSACTION has fields for BUSINESS_TIMESTAMP, SUBMITTED_TIMESTAMP, and COMPLETED_TIMESTAMP. Suppose a business object needs to exist that has an "arrived" and "processed" timestamps, which most easily relate to a BUSINESS_TIMESTAMP and COMPLETED_TIMESTAMP.
Note: Use of the Eclipse-based Detection Toolkit allows you to create the business (logical) object without concern for intimate ICFM data model knowledge, as the tooling handles maintaining the integrity of the model.
Related Information
Was this topic helpful?
Document Information
Modified date:
26 September 2022
UID
swg27049426