Documentation for a newer release is available. View Latest

IPF Operational Data Store - ODS

Overview

IPF ODS provides insight into the end-to-end lifecycle of a payment, regardless of the (payment/message) type or the channel through which it was received. The end-to-end lifecycle of a payment can be the result of the execution of multiple processes, such as processing of customer credit transfer instruction (pain.001, that results in a pacs.008 that is sent to a CSM), a pacs.002 payment status update (as a response to the pacs.008), a cancellation request (camt.056) and the response to the cancellation request from the CSM. The data in the ODS may also be accessed by customers via one of their banking channels to check the status or view the details of a payment. It is also possible that the ODS is queried by other bank applications, for instance the application that generates account statements for customers and needs to enrich the bookings (which hold limited amount of data) with additional payment data to provide the customer with all relevant data it needs for its operations (e.g. reconciliation of accounts receivables).

The ODS includes a set of APIs with which applications (such as IPF Operator GUI, but also non-IPF applications) can search for payments, the details of a payment, the processing logs as well as the messages that are exchanged with external systems/parties.

The data source of the IPF ODS is the processing events and messages that are stored by the IPF processing nodes during the processing of payments/transactions in the event store.

To put the ODS a bit more in a business context below follows several examples of queries that operators need to be able to perform:

  • An operator needs to be able to search for payment instructions (PmtInf of a pain001) that have been issued by a customer on basis of one or more search criteria like instruction reference, end-to-end reference, transfer currency, transfer amount (range), submission date (range), delivery channel, payment type, debtor account, etc.

  • An operator needs to be able to search for payment transactions (CdtTrfTxInf) that have been submitted by a customer, irrespective of the instruction in which they have been submitted, using one or more search criteria like end-to-end reference, transfer currency, transfer amount (range), submission date (range), payment type, creditor account, etc. This is required as it may not always be known (e.g. by the originating customer) in what instruction a certain transaction has been submitted to the bank.

An operator needs to be able to search for a specific transaction (CdtTrfTxInf) that has been sent to a CSM (GrpHdr of a pacs008). Therefor the CdtTrfTxInf (object) that is received in the pain001 message needs to be linked/associated with the GrpHdr of the pacs.008 in which the transaction is sent to the CSM.

An operator needs to see which payment status updates (potentially multiple over the lifecycle) have been sent to the originating customer for a specific payment instruction (PmtInf), via one of the customer channels. To enable this, the relevant CdtTrfTxInf from the incoming pain.001 message must be linked to the GrpHdr of the pacs.008 message in which the transaction was sent to the CSM.

  • An operator needs to be able to search for any MDS object that has been processed in IPF to see what actions have been performed during processing in IPF.

Licensing

The ODS service is an Additional Optional Module (AOM) for which you require an additional license, please check your license agreement if in any doubt.

Summary

ODS provides a unified, and eventually consistent insight into the end-to-end lifecycle of a payment, which will be the result of execution of multiple processes, such as initiation, execution, clearing and settling, cancellation, and integration with other bank systems, such as fraud and sanctions checks.

There are two deployable applications, ingestion, and inquiry, and they both share a data model - ingestion writes (mostly), and inquiry reads (mostly).

Ingestion consumes IPF Processing Data, builds an ODS data model representation and persists the data in a way in which it can be queried. It also builds more complicated views from the raw ODS data model.

Inquiry is an api that allows flexible querying of the ODS data model. It supports the IPF Operational GUI, and other bank systems that require information about payments.