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
|Account Report||Camt Message||Description|
|Bank to customer account report||camt.052.001.10||Intraday balances and transactions.|
|Bank to customer statement||camt.053.001.10||Prior-day balances and transactions.|
|Bank to customer debit / credit notification||camt.054.001.10||Transaction data every time a debit or credit is booked on the account.|
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.
|Balance Code||Balance Type||Description|
|CLAV||Closing available||Closing balance of amount of money that is at the disposal of the account owner on the date specified.|
|CLBD||Closing booked||Balance of the account at the end of the pre-agreed account reporting period. It is the sum of the opening booked balance at the beginning of the period and all entries booked to the account during the pre-agreed account reporting period.|
|FWAV||Forward available||Forward available balance of money that is at the disposal of the account owner on the date specified.|
|INFO||Information||Balance for informational purposes.|
|ITAV||Interim available||Available balance calculated in the course of the account servicer's business day, at the time specified, and subject to further changes during the business day. The interim balance is calculated on the basis of booked credit and debit items during the calculation time/period specified.|
|ITBD||Interim booked||Balance calculated in the course of the account servicer's business day, at the time specified, and subject to further changes during the business day. The interim balance is calculated on the basis of booked credit and debit items during the calculation time/period specified.|
|OPAV||Opening available||Book balance of the account at the beginning of the account reporting period. It always equals the closing book balance from the previous report.|
|OPBD||Opening booked||Book balance of the account at the beginning of the account reporting period. It always equals the closing book balance from the previous report.|
|PRCD||Previously closed booked||Balance of the account at the previously closed account reporting period. The opening booked balance for the new period has to be equal to this balance. Usage: the previously booked closing balance should equal (inclusive date) the booked closing balance of the date it references and equal the actual booked opening balance of the current date.|
|XPCD||Expected||Balance, composed of booked entries and pending items known at the time of calculation, which projects the end of day balance if everything is booked on the account and no other entry is posted.|
The most common types of balances are OPAV, OPBD, CLAV, and CLBD.
In addition to account balances, account reports provide transaction data. A transaction entry contains the following information:
|Amount||The amount of the transaction.||✅ Yes|
|Currency||The currency of the transaction.||✅ Yes|
|Value Date||The date when the funds become available or unavailable.||✅ Yes|
|Booking Date||The date when the transaction is posted on the account.||✅ Yes|
|Bank Transaction Code||A standardised set of code which defines the domain, family and sub-family of the transaction.||✅ Yes|
|Remittance Information||The description of the payment, as inputted by the payment originator or the bank holding the account.||❌ No|
|Account Holder Name||The name of the account holder.||❌ No|
|Account Holder Account Number||The account number of the account held by the bank.||❌ No|
|Counterparty Name||The name of the counterparty.||❌ No|
|Counterparty Account Number||The account number of the counterparty.||❌ No|
|End-to-end ID||The end-to-end ID of the payment, as inputted by the payment originator or generated by the payment originator’s system.||❌ No|
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:
|Domain Code||Domain Name||Family Code||Family Name||Sub-family Code||Sub-family Name|
|PMNT||Payments||RCDT||Received Credit Transfers||ESCT||SEPA Credit Transfer|
|PMNT||Payments||MCRD||Merchant Card Transactions||POSC||Credit Card Payment|
|PMNT||Payments||RRCT||Received Real-time Credit Transfers||ESCT||SEPA Credit Transfer|
|ACMT||Account Management||MDOP||Miscellane-ous Debit Operations||COMM||Commission|
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:
|ACCP||Payments have passed technical and functional validations.|
|ACSP||Payments have been accepted and processed.|
|PNDG||Payments have been put on hold. A reason is included.|
|RJCT||Payments have been rejected by the bank.|
|ACSC||Payments have been processed and settled.|
|PART||At least one payment of the file is accepted and processed, and at least one payment of the file is rejected.|
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:
|Status Code||Payment GroupLevel||Individual Payment Level|
|ACCP||✅ Yes||✅ Yes|
|ACSP||✅ Yes||✅ Yes|
|PNDG||✅ Yes||✅ Yes|
|RJCT||✅ Yes||✅ Yes|
|ACSC||✅ Yes||✅ Yes|
|PART||✅ Yes||❌ No|
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.
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.
Other articles you might like
Not sure where to start?
Let’s talk about how we can work together to accelerate your payment flows. Get a demo of our platform, explore our pricing, or get started right away.