How fintechs can make the most out of their bank statements

Most regulated fintech companies, namely payment and electronic money institutions, partner with banks to manage customer funds and send and receive payments on behalf of their customers.

As such, having complete visibility of what happens in your bank accounts and with your payments is vital to run compliant and efficient operations.

But understanding and leveraging information banks make available can unlock powerful use cases, in addition to the classic (and legally required) reconciliations and daily view of your account balances.

What are bank statements, and what info do they contain

Let’s start by going through the type of reports banks usually make available to their customers and what information they include.

Account reports – or CAMT messages

CAMT messages are a set of standard messages defined in the ISO 20022 standard that is used across many payment schemes worldwide to codify how information should be exchanged between financial institutions and their customers.

Depending on the schemes, CAMT messages are used as defined in the ISO 20022 standard or with slight variations (e.g. SEPA) or replaced by equivalent messages (e.g. Bacs).

For the sake of simplicity, we’ll focus on the messages as defined in the ISO 20022 standard.

ISO 20022 specifies three distinct types of account reports and the corresponding CAMT messages.

Account report types

Depending on their capabilities, banks might generate camt.052 intraday account reports every few hours and camt.054, debit / credit notification account reports every few minutes, and camt.053 prior-day account reports shortly before or after midnight.

Although they contain the same transactions, debit / credit notification, intra-day, and prior-day account reports can be difficult to reconcile, as they do not always use a common ID for a given transaction.

Banks make both camt.052 and camt.053 available to customers because camt.052 contains information that might not be final. Indeed, a debit transaction for instance might correspond to a payment made from the bank account to an outside beneficiary, that has been accepted by the bank but not sent to the CSM yet. This payment can be blocked at the CSM level for technical reasons, or rejected by the beneficiary bank for various reasons.

Therefore, the corresponding transaction might appear in the intra-day report, and the intra-day balance might reflect this transaction, but if something goes wrong, the intra-day report might not represent the reality of the bank account at the end of the day.

Account balance types

camt.052 and camt.053 account reports contain account balances. The ISO 20022 standard specifies the different types of balances which can be included in account reports.

The most common types of balances are OPAV, OPBD, CLAV, and CLBD.

Transaction Data

In addition to account balances, account reports provide transaction data. A transaction entry contains the following information:

As payments go through multiple parties during their lifecycle, including at least two PSPs and one CSM, the payment data might be transformed or lost, depending on the PSP or CSM’s capabilities. This can result in difficulties in understanding and reconciling transactions.

Bank Transaction Codes

Bank transaction codes are a harmonised set of codes defined by the ISO 20022 standard, aiming to categorise transactions by assigning them domain, family, and sub-family codes. Some bank transaction codes frequently used include:

Payment status reports – or pain.002

A payment status report (PSR) indicates if and how the payments contained in the payment file have been processed by the bank.

Similarly to account records that are usually sent as camt messages following the ISO20022 standard, PSRs are also standardised in ISO20022, as pain.002 messages. And similarly to camt messages, pain.002 messages, small variations or close equivalents are used across various payment schemes.

Common processing statuses include:

PSRs contain status updates at payment group and individual payment levels. Statuses can either be final or non-final. A final status means that the payment cannot be changed to another status later on. A non-final status means that the status of the payment will likely evolve later on.

If all the payments of a PSR have the same status, then the whole group can be tagged with this status. Conversely, if the group contains payments that have different statuses, the group status will be PART and every payment details will contain the individual payment status. The following table summarises the different statuses payments can have and whether the status is at a payment group or individual payment level:

The use cases unlocked by account reports and payment status reports

Now that we understand the main types of information banks make available to their customers, let’s explore the use cases they unlock, especially for fintech companies.

Treasury management

A classic use case for account reports and payment status reports for fintech and other types of companies alike is treasury management. More specifically, in our case, visibility on your treasury.

Through intra-day and prior-day account reports, companies have access to their account balances as calculated by their banks, according to the transactions that happened on their bank accounts.

Account balances reflect the liquidity available in companies’ bank accounts and are, therefore, vital for any business.

Real-time treasury management

While intra-day and prior-day balances are enough for most companies, some fintech companies might require a more real-time view of their treasury. To do so, they will calculate intermediate balances on their own, based on intra-day or prior-day balances made available by their bank.

They will use camt.54 ​​bank to customer debit / credit notification to refresh balances based on transactions before the bank emits intraday balances, and sometimes PSR to take into account successful sent payments and update balances in real-time.

While these calculated balances might not be a perfect representation of reality, they allow fintech companies to move large amounts of money daily to ensure they always have the right level of liquidity in their accounts.

Notify customers of their own balances and payment statuses

Regulated fintech companies hold customer funds and send and receive payments on behalf of their customers. Just like anyone would expect from their bank access to their balance and payment statuses at any time, electronic money and payment institutions customers expect the same.

Regulated fintechs will leverage the information they receive from their bank to update their customer balances and send them notifications regarding their sent and received payments.

Trigger money workflows, such as customer funds safeguarding

Information banks provide to their customers can also help them automatically trigger operational or regulatory flows of funds. In the case of customer funds safeguarding, for instance, regulated fintechs have to transfer their customers’ incoming payments to a safeguarding account in less than 24h.

Using account reports, they can identify these payments and trigger the payment of corresponding amounts from their settlement accounts to safeguarding accounts.

Speaking of settlement accounts, fintechs need to always keep sufficient funds there to honour outgoing payments. Using account reports, PSR and the payment orders from their own customers, they can estimate if they have enough funds in their settlement account and, if not, transfer more money to this account.

How to unlock bank statements

As we covered, information that banks make available to their customers can unlock powerful use cases. But fintech companies must obtain and process account and payment status reports to do so.

Doing so comes with multiple challenges.

First, these camt and pain messages are usually made available by the banks in the form of XML files on SFTP file servers. To leverage banks' information automatically and as soon as they’re made available, fintech companies need to build that direct, real-time connectivity between the banks’ servers and their own systems, which can be a complex task.

Second, as noted above, information will be made available through XML files. And fintechs internal systems aren’t exactly made to ingest and understand XML files. Companies, therefore, have to build systems that will parse the files and find and process the correct information within these files.

What’s more, the format of these XML files will change between payment schemes and even banks. So working with several banks will mean rebuilding this parser several times.

Finally, once this information is identified and understood, it must be distributed to the fintech’s systems. It requires building APIs and webhooks that can be integrated into the fintech’s systems.

Using Numeral to leverage bank information in real-time

While automatically having access to bank accounts information in real-time and being able to leverage it in your internal systems is powerful, it can represent a significant product and engineering project to so.

Numeral is a bank orchestration platform that comes with built-in integrations to banks and automatically fetches and processes pain.002, camt.52, camt.53, camt.54 and many more files and messages to make them available to fintech companies via API, webhooks and a central dashboard.

If you want to leverage bank information to improve your payment operations, do not hesitate to contact us.