Payments are key to the operations of companies across a number of industries such as financial services, insurance, real estate, or temp work. Yet, scaling payment operations is complex and error-prone. In this article, we explain how Numeral abstracts the complexity of initiating, tracking, and reconciling payments by capturing the entire lifecycle of a payment in a payment order.

The required data and where to retrieve it

The first challenge of tracking payments through their entire lifecycle is that payments will go through multiple systems managed by multiple parties before reaching the bank account of their beneficiary.

Therefore, there isn’t a single source of truth for retrieving the status of a payment through this lifecycle.

In the scenario of a payment or electronic money institution (PI or EMI) sending a payment on behalf of its customer, the payment will usually go through the following systems.

PI/EMI internal systems

When a customer initiates a payment from its PI/EMI mobile or web application, this payment is usually recorded as a line in a database of the PI/EMI’s core systems.

Payments go through various checks in these systems, including internal business approvals (adequate balance, number of payments per day, …) and AML-CFT checks.

A payment can be stuck at each of these steps, and it is therefore important to be able to surface if and why a payment fails at these steps.

Retrieving payment data at this stage will usually be done through API calls to the application, SQL requests to the database or download of XML files for legacy systems.

PI/EMI partner banks

Partner bank system

Most PIs and EMIs aren’t direct participants in payment systems. They rely on partner banks to access payment schemes as indirect participants or corporate customers.

These partner banks will effectively execute the payments when given the order by the PI/EMI.

Banks will run their own checks before sending a payment on the payment system, including:

• Making sure the payment contains all the required information in the correct format, such as the beneficiary account number or its address for international payments

• Making sure the originating account has sufficient account balance

• Performing its own AML-CFT checks

Partner banks usually make the data related to the status of the payment in their internal systems through payment status report (PSR) XML files. These files must be downloaded from the bank’s SFTP server.

Here are the payment statuses usually available in SEPA payment PSRs

Clearing and settlement management systems

After a payment goes through the partner bank’s internal systems, it is sent to the clearing and settlement management system (CSM), which is the system all banks of a given payment system, such as SEPA, Bacs or FPS, connect to exchange payments.

While it is a very rare case, the CSM can itself reject a payment for various reasons. If it does, it will send information related to the rejection of the payment to the partner bank, which will forward it to the PI/EMI in a PSR.

Retrieving, parsing and normalising the payment tracking data

As we discussed above, the data required to track a payment across its entire lifecycle is spread across entities, systems and formats.

The first step of tracking a payment is to retrieve this data. A payment tracking system will need to be integrated with the system that initiates the payment, but also with the bank's cash management system from which the payment is sent to retrieve PSR and account statement files.

Building such integrations isn’t trivial, and will vary from one bank to another, making the challenge even greater for PIs and EMIs working with multiple partner banks.

In addition, each file often contains information about multiple payments or transactions. Identifying individual payments and transactions and information about their status in these files across all banks and internal systems is complex.

Matching the data

Once all the required data is retrieved to track a payment, the different data sets need to be matched to have a view of the entire lifecycle: payments initiated in the PI/EMI internal systems need to be matched with the right payment status from the PSR and reconciled with the right transaction on the account statement. When a payment is returned, the return needs to be reconciled with the corresponding transaction and attributed to the initial payment.

As mentioned in the previous section, the different files containing information about payment statuses will often contain information about multiple payments and transactions. Also, many reconciliations involve the matching of one transaction with multiple payments. This means that a comprehensive payment tracking system must manage one-to-one, one-to-many and many-to-many matching data models.

Making sense of the data: reason codes

In order to be the most useful, a payment tracking solution should not only be able to monitor the status of a payment but why a payment failed if it did fail.

Rejected and returned payments come with reason codes that detail the reason for the rejection or the return. Each payment system has its specific reason codes (SEPA, Bacs, FPS).

An ideal payment tracking solution should retrieve reason codes from bank files, link them to the tracked payments and interpret them. Advanced payment solutions can even automatically retry a failed payment based on the reason code for the return or rejection.

Exposing the data

Payment tracking information is, of course, meant to be made available to fintech customers, internal teams or other internal systems. A payment tracking solution should, therefore, offer the right interfaces to do so.

API and webhook

For PIs and EMIs to expose to customers the status of their payments in their mobile and web applications in real-time, they need to retrieve it from the payment tracking system programmatically.

The payment tracking solution must, therefore, offer API and webhooks to do so.

Dashboard

PIs' and EMIs' internal teams must have easy access to payment statuses in order to answer customer questions, quickly identify payment issues, and run analyses in order to improve their payment operations.

A dashboard clearly exposing the status of initiated payments, their reconciliation status and the possible returns linked to payments is therefore key.

From batch to straight-through processing

Real-time payment tracking involves retrieving and processing information related to the payment lifecycle as soon as it is made available by the banks.

It requires the constant monitoring of banks’ SFTP servers or other bank connectivity channels and the instant processing of any file made available.

Payment tracking solutions that aim at providing real-time payment tracking must be built from the ground up for it. Incumbent cash management or accounting solutions offer payment tracking at a large scale but rely on batch processing: payment-related information is retrieved and processed once a day, making it impossible to inform customers about their payments in real time or to identify and fix payment issues quickly.

How Mambu Payments supports fintech companies tracking their payments

Mambu is a payment technology provider. We provide the infrastructure for fintechs to connect to partner banks, access schemes, and automate payment operations.

A key capability of our platform is payment tracking.

Thanks to direct integrations with a large number of banks, Mambu can retrieve and process PSRs and account statements as soon as they are made available by the partner bank.

Mambu automatically updates the status of payments based on this information and automatically reconciles available transactions with the corresponding payments.

Through a user-friendly dashboard, support and operations teams can access the latest status of all their payments from a single place, as well as status details on each payment and, when relevant, the return and reconciliation linked to each payment.

It enables them to know if and why a payment failed in a few seconds.

Mambu also comes with a comprehensive API and webhooks to receive real-time notifications whenever a payment status changes and alerts when payments fail.