From improved customer experience to increased support and payment teams productivity and optimised liquidity management, there are numerous significant benefits for fintech companies track their payments in real-time.
Due to the heterogeneity of payment data, ways to access it and the complexity of reconciling these various sets of records, automating real-time payment tracking isn’t trivial.
In this blog, we explore all the elements to consider when choosing or building your payment tracking solution.
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.
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.
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:
|Payments have passed technical and functional validations.
|Payments have been accepted and processed.
|Payments have been put on hold. A reason is included.
|Payments have been rejected by the bank.
|Payments have been processed and settled.
|At least one payment of the file is accepted and processed, and at least one payment of the file is rejected.
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.
When a beneficiary bank receives a payment from another bank through its CSM, it can itself decide to accept or return the payment (or reject it in the case of SEPA instant payments).
A beneficiary bank can return a payment for technical, business or fraud reasons, such as an incorrect account number, the beneficiary account being closed or blocked, or the suspicion of a fraudulent payment.
When it happens, the beneficiary bank sends a message related to the return to the CSM, which forwards it to the originating bank, which will report it to the PI/EMI in an account statement.
In such a case, the initial payment will be considered and flagged as successful by the originating partner bank, and a transaction corresponding to this payment will appear in the account statement. A return related to this payment and its corresponding transaction will also appear in the account statement file.
When the beneficiary bank accepts the payment, the payment is settled through the CSM, and the CSM forwards the information to the originating bank, which will book the corresponding transaction on the PI/EMI bank account. The information will be available to the PI/EMI through its account statements.
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.
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.
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.
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.
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.
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.
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.
Numeral 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, Numeral can retrieve and process PSRs and account statements as soon as they are made available by the partner bank.
Numeral 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.
Numeral also comes with a comprehensive API and webhooks to receive real-time notifications whenever a payment status changes and alerts when payments fail.
If you would like to know more about how Numeral could help you better track your payments, contact us.