Customer-centric model

The customer/counterparty model contains a set of attributes for the customer account (account number, account name, and so on) and counterparty account, plus one extra attribute that indicates the role of the customer account in the transaction (creditor or debtor).

The customer-centric model has the following characteristics:

  • Provides a single view of the customer account and its transaction activities.
  • Role of the customer in a transaction is defined through an extra attribute.
  • Uses standard index for profiling functions.
  • Requires only one set of masterdata attributes, hence no waste of memory.
  • Queries and counters have access to all transactions no matter of the role of the customer.
  • Simple definition of multiple relationships between customers and their accounts, which is required for AML transaction monitoring.
  • Requires separation of payment messages by customer account role and a duplication of data mappings.

Data mapping

Since most payment messages follow the originator/beneficiary concept, the mapping of message fields to data dictionary attributes needs to resolve which party in the transaction represents the customer. Since the customer can be either the originator or the beneficiary in a transaction, two message types (MTIDs) and mappings are required when the payment message is ingested into IBM® Safer Payments. One MTID represents the originator as the customer, the other MTID represents the beneficiary as the customer. Each MTID sets the flag that indicates the customer’s role in the transaction (or direction of the payment).

Figure 1. Data mapping diagram
The graphic shows that the MTID sets the flag that indicates the customer’s role in the transaction (or direction of the payment) as either originator or beneficiary.

Profiling

To allow profiling of transactional behavior of the customer account, a standard index is required on the customer account attribute. Another standard index on the counterparty account can be created to allow profiling of the counterparty account. The standard index holds all transactions of the customer account, independent of the role of the customer account in a transaction.

To consider only transactions where the customer account is in either one of the roles (either originator or beneficiary), the flag that indicates the customer account’s role in the transaction must be added as a condition to the query, counter, and so on.

Masterdata

Setting up masterdata in this model is straightforward since masterdata is typically only available for the customer but not for the counterparty. Since all customer accounts can be found in a single attribute, masterdata definitions must be set up only for the customer account attribute.