This topic describes about the information on relationship pricing.

Pricing Decision service (PDS) in its vanilla flavor offered charges, pricing and decisioning capability using only the facts passed by the product processor in the payload. With relationship pricing, PDS becomes capable to price based on attributes related to the customer’s relationship with the bank. PDS can retrieve such attributes (facts) on its own and can use these in addition to the ones passed by the product processor. The facts can be either retrieved online from other modules or can be fetched from its local store. Currently, relationship pricing sources does not perform complex calculations using these attributes. It stores them and makes them available as features and facts in RP models.

The module has been enhanced with various ingestion mechanisms to populate its local store. The store is flexible, extensible and has an efficient entity-based model. Bank can create new aggregates and configure attribute retrievals using mechanisms such as events, API calls and bulk data transfers. The next few sections describe the mechanisms of creating aggregates, the facts and the data retrieval configurations.

Aggregate Configuration describes creating metadata for holding aggregate data.

For example – When a Party aggregate is created using the screen, it creates a table to hold the Party data. Multiple aggregate tables can be created to hold facts pertaining to the aggregate, that are then used in Relationship rules.

Parse Configuration and Execution Configuration describe the creation of configurations for online retrieval of information. Example – In an online manual disbursement execution, if savings account attributes are required to be fetched, RP looks up these configurations to retrieve data online. From the disbursement payload, it is possible to fetch the partyid and then lookup the party service online to fetch party attributes. Execution Configuration describes the step sequence of calls needed and Parse Configuration describes the mechanism in each step. These sequences and the steps are loosely coupled and can be assembled dynamically to wire various data retrievals.

Finally, Transport Fact Mapping describes the configuration needed to do bulk population of the aggregate data into the tables created using Aggregate Configuration. For example – bulk population of payment data into the Payment table created.

This topic contains the following subtopics:

• Aggregate
  This topic describes the information about the aggregate feature.
• Parse Configuration
  This topic describes the information about the parse configuration feature.
• Execution Configuration
  This topic describes the information about the execution configuration feature.
• RP Online Configuration
  This topic describes the information about the relationship pricing configuration.
• Transport Fact Mapping
  This topic describes the information about the transport fact mapping feature.