How Exactly will ISO 20022 fix reconciliations?

Any TMS morning starts with updating and reconciling the cash positions across accounts by a daily upload of electronic bank statements (MT 940, 942..). This financial reconciliation focuses on balances and net credit and debit movements across the accounts and helps treasurers build an image of liquidity and dealing capital and other requirements for the day. 

 By contrast, ERP systems have to operationally reconcile and this needs more detailed information, like transaction references, remitter identification and remittance information delivered by the payment networks and banks.

The operational reconciliation is traditionally conducted separately, applying different reconciliation logic to the debits versus the credits on a statement. Payments reconciliation recognises that a payment run could be a controlled activity against which there's a transparent record within the ERP of what debit amount should appear on the statement and on which date. Which is therefore quite straightforward.

But, statement credits, from incoming payments and cheques, present a tougher challenge. Additional remittance information may arrive by separate means (free format MT 199), and even at different times than the statement. Obtaining a 3-way match between statement credit entries, remittance information and open invoices is labour intrinsic, time-consuming and infrequently requires advanced technologies for auto reconciliation which bring a brand new set of challenges.

To summarize, the key challenges with the operational account reconciliation for a bank or corporate treasury process falls into four main categories:

Operational Set-Up:

No standardisation of systems and processes.

No key performance indicators (KPIs) or not aligned between the shared service centre (SSC) and also the core business operating units.

Technology:

Limited capabilities within existing enterprise resource planning (ERP) system around auto-matching rules-based logic and skill to process proprietary reporting formats.

Increased dependency thereon resources for change.

Data Quality:

Partial or combined payments.

Truncated or missing information.

Separate remittance information/different data formats.

Local Payments Practices:

Differences in local in-country clearing systems.

Available and preferred payment and collection methods.

Can ISO 20022 fix all of these?

ISO 20022 offers great potential benefits for cross border payments and global trade because of, amongst other reasons, the numerous amount of transactional and remittance data passing between the various parties, which incorporates an

ERP or treasury management system at both ends.

With over 400 message types covering all aspects of banking and financial services, some are specific to a specific industry body, others more generic and more widely accepted.  Messages are grouped into business domains and groups like Trade Services (tsrv), Cash Management (camt), Securities Trade (setr) and Payments Initiation (pain).  Beyond the message formats themselves, ISO 20022 sets out the usage and business process flows, between the varied actors in business scenarios. 

                                                         Source - iso20022.org

With 1500+ fields, camt.053 can solve the challenges highlighted earlier. It is a message sent by the account servicer to an account owner or to a party authorised by the account owner to receive the message. It is used to inform the account owner, or authorised party, of the entries, booked to the account, and to provide the owner with balance information on the account at a given point in time.

It can be used for various end of cycle statement reporting - Daily, weekly, monthly, yearly. 

The top 3 benefits will be 

Enhanced Data 

Exception items, requiring manual reconciliation, are greatly reduced which allows daily and month-end bank account reconciliation deadlines to be met, this is because each of the transaction details is mapped into an XML tag which enables Straight Through Processing. 

Few examples. 

E2E identification (invoice reference, Shipping date..etc) has a specific field which enhances auto-match capabilities at both sending and receiving parties end. 

Fees charged on transactions can be mapped with details against deducting party and adjusted accordingly in the internal accounts. 

For cross border transactions, including counter currency code, original currency amount, spot transaction rate, FX spot contract number. These values can be mapped to automatically calculate realized FX gain/loss on the transaction, eliminating the need for manual reconciliation.

Enhanced risk management 

Structured data supports more effective compliance through comparisons to watch lists which in turn helps organisations meet expanding risk management, regulatory and compliance. 

We expect standardised compliance to Legal entity identifier (LEI) and merchant IDs to transactions. 

Enhanced Structure

Enhanced bank account balance and transaction summary values which includes opening/closing ledger with balances, a summary of transaction details. 

Statement Pagination provides a page number of the statement. 

The electronic sequence number allows easy recognition of statement order. 

Copy Duplicate Indicator to identify an additional statement from the original. 

Reporting source allows the account servicer to add details of account and Dept. 

(Several mandatory and optional fields are not covered in this article, refer the User Hand Book)

Understanding camt.052, camt.053 and camt.054 - 

camt.052 – Bank to Customer Account Report 

This is intraday information, provides the customer with a nearly real-time view of their account(s). It will replace the MT942.

camt.053 – Bank to Customer Statement

This is previous day statement, provides the customer with detailed and structured information on all entries booked to their account for the previous day. The camt.053 will replace the MT940.

camt.054 – Bank to Customer Debit / Credit Notification

camt.054 provides the customer with specific account debit and account credit information, it will replace the MT900 (Confirmation of Debit) and MT910 (Confirmation of Credit) messages

Initial challenges will be around the learning curve and implementation period, during the coexistence period old and new formats will have to be processed. TMS / ERP systems may require development programmes, instead choose middleware applications. 

Simply put by ABN AMRO

Arguments for choosing the CAMT.053 format

•  You wish to see the full reference and description as 2 separate fields in the reporting. This may be an advantage in the case of automatic reconciliation.
•  You need to see underlying details of batch payments. The CAMT.053 format informs you of the total amount of the batch and the details of the transactions.
•  You benefit from receiving all feedback in one file. You can optimize your processes and systems on the basis of the XML format. This can help to reduce maintenance and simplify the processes.

Arguments for retaining the MT940 format

•  It is sufficient for you to have details about batch payments at a principal level only.
•  Your systems are unable to process the larger data volume of the XML format.
•  The delivery deadline of the MT940 reporting better suits your follow-up processes.

MT942 or CAMT.052?

•  For intraday reporting you may choose which format to use. The arguments to choose for one format or the other are the same as for end-of-day reporting.

            Source - UK RTGS

Opportunities

Not limited to, but additional and significant value can be unlocked in the financial supply chain through the expanded and consistent use of ISO 20022 message standards for payment processing and compliance requirements.

Summing-up

Payments Standardisation will bring new opportunities and treasuries should consider the new standard, take time to analyse payments and identify opportunities for improvement. However, allow enough time to work with your technology partners to understand the need and size of implementation. You may want to update the ERP systems or just use a translator because legacy systems will exist for your banking partners. 

ISO 20022 is a journey, not a destination.