Data integrity is a critical component in the realm of financial transactions, particularly when it comes to managing and interpreting payment information. The Customer Data Bridge (CDB) is a PagoNxt Payments Hub data product that provides the authoritative external data feed of a client’s payment information for informational and analytical purposes. It is based on the normalised and aggregated data managed by Data Domain, which acts as the Single Source of Truth for payment processing within Payments Hub.
Its main purpose is to serve payment data to be integrated into analytical and reporting customer applications, such as data lakes and other customer information applications. It is strictly intended for informational or analytical purposes and must not be used for operational, transactional or payment progression use cases (*).
CDB consumes the normalised payment data stream produced by Data Domain and updates payment information in near real-time. It stores this information in a customer-agnostic payment data model designed specifically for external consumption.
Stored information includes all the relevant information about the payment, such as references and statuses that the payment goes through in the different steps of the processing. This includes payment identifiers, ISO message references, execution points, processing statuses, functional statuses and relevant rejection or cancellation reasons.
Data Retention and Scope
CDB is designed as a feed product with limited data retention. Its storage is transient and intended to facilitate downstream integration into customer systems. Long-term historical storage and customised querying capabilities are the responsibility of:
Customer systems (e.g. data lakes, master payment databases), or
A dedicated Customer Payments DB solution where applicable.
CDB is not intended to replace operational databases or serve as a long-term historical repository.
Delivery Mechanisms
Payment data is delivered through the following mechanisms (**):
Streaming:
Near real-time publication of payment updates to Kafka topics. Relevant changes in the payment lifecycle for a specific client are delivered at the time of generation. No additional transformation is applied beyond the standardised CDB data model.
File extraction:
Periodic extraction of payments for a defined time window.
By default, extraction takes place daily at 00:00h in the client’s time zone, but frequency and timing can be configured.
Supported formats:
JSON
JSONL
ZIP
GZIP
Payments Hub Data Flow – Conceptual Overview
Data is initially generated in ISO 20022 messages by the client or the Clearing House.
During payment processing, events are generated and propagated to the Data Domain. Data Domain performs event sourcing, consistency control, enrichment and aggregation before distributing the normalised data to downstream data products.
Payments are managed by customer operators in the customer portal on a daily basis.
CDB consumes the normalised output of Data Domain and serves it to customer informational and analytical systems.
Payments Hub data flow in a nutshell
Data is initially generated in ISO 20022 messages by the client or the Clearing House
Data is propagated via events from the payment flow to the Data Layer to be used by different data products
Payments are managed by customer operators in the customer portal on a daily basis.
The customer data bridge serves data to feed customer's information and analytical systems.
Architectural Positioning
Within the Payments Hub data ecosystem:
Data Domain:
Single Source of Truth for payment processing. Supports operational and informational use cases internally.Payments Intelligence:
Provides analytical insights, metrics and value-added information derived from payment data.Customer Data Bridge (CDB):
Standardised external data feed for customers’ informational and analytical systems.
Read-only, non-operational.Customer Payments DB (where applicable):
Customised database solution tailored to specific channel query needs and high-retention requirements.
Important Notice on Standardisation
In order for these data products to effectively manage event information, the data must be provided in a standardised format, normalised across the various entry and exchange interfaces of the process.
To achieve this, data from ISO messages must be accurately mapped, including supplementary data (***) as defined and normalised by Payments Hub.
The CDB data model is customer-agnostic and based on ISO-aligned concepts. Any local adaptations (e.g. local statuses, custom mappings, additional indexes or retention extensions) must be explicitly governed and, where applicable, funded as customer-specific customisations. The product baseline remains standard and reusable.
When standard mappings are correctly applied, data can be collected, stored and served consistently across all services.
(*) Its role is not to provide information for the daily operation or management of payments.
(**) All product contracts and formats are defined exclusively by the Payments Hub.
(***) Additional information that can not be captured in the structured fields and/or any other specific block. For more information, visit the ISO 20022 public documentation