Taking Bank Statement Reconciliation to the Next Level – is ISO20022 XML the Answer?

What are the key challenges with the operational account reconciliation process? For Citi, they fall into four main categories:

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.

Operational Set-Up:

  • No standardisation of systems and processes.
  • No key performance indicators (KPIs) or not aligned between the shared service centre (SSC) and the core business operating units.


  • Limited capabilities within existing enterprise resource planning (ERP) system around auto-matching rules based logic and ability to process proprietary reporting formats.
  • Increased dependency on IT resources for change.

All of the above adversely impact the ability to implement a smooth and efficient account reconciliation process.

Improving automated matching rates will deliver further financial and operational savings and process efficiency gains, moving corporates into the ‘best in class’ operating model category through achieving the following:

  • Improved cash application through higher auto matching rates.
  • Reduce days sales outstanding (DSO).
  • Improved customer service as credit lines are freed up.
  • Improved risk management, through earlier identification and management of late paying clients.

Major banks have long recognised the importance of helping their clients achieve greater straight through reconciliation (STR). Establishing a centralised global data repository that enables the provision of enriched itemised statement reporting has helped corporate clients improve both the account payables and account receivables (A/P and A/R) process. This architecture also ensures this richness of information is broadly format agnostic.

With just under 1,600 fields and benefiting from the harmonisation work completed by the common global implementation (CGI) group, it is easy to understand the growing interest around the camt.053 XML statement message for the multi-banked corporate community. The next section looks at the specific challenges and benefits that technology group Itron Inc has achieved through adoption and considers some of the areas that can still be improved upon.

Case Study: Itron, Inc

Itron is a global multinational corporation (MNC), providing technology solutions and services to the utility industry with subsidiaries in more than 30 countries. Itron became a corporate SWIFT participant in November 2012, leveraging the Standardised Corporate Environment (SCORE) model, and currently receives end-of-day bank statement reporting from close to 35 banking partners, using a mixture of MT940, Bank Administration Institute (BAI) and camt.053.xml.

Itron also receives current day statement reporting from six banking partners using MT942 and BAI. Itron has been receiving camt.053.xml statements from three global partner banks for the past year and is currently testing this format with three additional partner banks.

The benefits of migrating all of our banks from legacy MT940 and BAI statement reporting to camt.053.xml can be grouped into three main areas:

  1.  Enhanced data.
  2.  File management.
  3.  Enhanced risk management.

Enhanced data:

Transaction details mapped into discrete eXtensible markup language (XML ) fields (tags) enable a higher degree of straight-through processing (STP), reconcilement, reporting and analysis. Exception items, requiring manual reconciliation, are greatly reduced which allows daily and month-end bank account reconciliation deadlines to be met. Here are four examples:

  • End to end identification (ID) number for payments initiated by Itron from the corporation’s Oracle ERP system, which allows for transaction automatching within both its IT2 treasury management system (TMS) and Oracle systems.
  • Foreign exchange (FX) details including counter currency code (SrcCcy), original currency amount (AmtCcy), spot transaction rate (XchgRate), FX spot contract number (CtrctId). These values can be mapped into the company’s ERP system to automatically calculate realized FX gain/loss on the transaction, eliminating the need for manual reconciliation. Mapping this information into the TMS allows for more effective analytics on FX spot related activity.
  • Fees charged on transactions (payments) if disclosed and provided in discrete fields (tags) can be mapped into both the TMS and Oracle and automatically recorded to the appropriate general ledger (G/L) account, while also allowing the underlying transaction to be automatically matched and reconciled. When fees are deducted from the principal amount of the transaction but not disclosed or broken out separately then auto-matching cannot occur and the transaction must be manually reconciled.
  • Enhanced related parties data including in some cases the international bank account number (IBAN) of the remitter of the payment, full name of remitter, SWIFT bank identifier code (BIC) of remitting bank, address of remitter and remitting bank. These values make it easier to apply the payment (in some cases through enhanced auto-matching). Enhanced related parties data is also important when receiving payments from organisations that use pay-on-behalf-of (POBO) or making payments to organisations that use receive-on-behalf-of (ROBO) structures and the ultimate remitter or beneficiary needs to be known.

Enhanced structure:

  • Contiguous statement for each bank account within the camt.053 vs. the legacy MT940 ‘pages’. Citi receive numerous MT940 messages per day (more than 2,000 on certain days) and often end up with missing ‘pages’ from some banking partners which creates significant work for the bank to follow up with the transmitting bank to resolve.
  • Ability to group reporting for accounts by region which allow for more effective monitoring of the expected receipt time (i.e. all accounts for Asia Pacific (APAC), Europe, the Middle East and Africa (EMEA), Latin America (LATAM) or North America (NAM) regions in distinct files).
  • Multiple transaction code types can be supported (i.e. SWIFT, BAI, ISO 20022 and proprietary) allowing the bank to leverage the most effective codes that represent the nature of the transaction in order to facilitate auto-matching, auto-journal entry creation, reconciliation, reporting and analytics.
  • Enhanced bank account balance and transaction summary values (which Citi uses as control totals for data validation and reporting) including:
     – Opening/closing ledger and available balances.
     – Summary of transactions and amounts, as well as summary of debit and credit transactions and amounts.
     – Float amounts and days availability on certain transactions (generally cheques) which support liquidity management and planning.

Enhanced risk management:

  • Enhanced transaction level data, when populated in the applicable defined XML fields (tags), can help support more effective compliance through comparisons to watch lists which in turn helps organisations meet expanding risk management, regulatory and compliance requirements including:
    ? Legal entity identifier (LEI). 
    ? Ability to link derivative and capital markets contracttransaction IDs to payment transaction numbers.
    ? Linking of credit facilities, letters of credit/banks guarantees, merchant IDs and other related services to payment transaction numbers.
  • Forward value dated funds availability (if large) is a critical element of the cash position/short term liquidity planning and oftentimes these values are not available in legacy statement formats.

Challenges to the corporate:

  • Initial learning curve of camt XML file structure schema compared to legacy BAI/MT940.
  • Inconsistent support for populating XML fields (tags) between banks (although great work by the CGI Group is helping drive harmonisation/standardisation of content and business rules).
  • Banks are just beginning to offer this format, so internal knowledge and expertise may me limited at this stage.
  • Limited other corporates to engage for knowledge sharing.
  • ERP/TMS systems may need to develop programmes to read XML statements, but support is expanding and many middleware applications can help.


In order to fully achieve the benefits of ISO 20022 XML statement reporting, the industry and the CGI working group need to further define the data definitions and business use cases.

An example of an opportunity for further discrete mapping for additional value and benefit is for populating extended remittance data details. The current use of the remittance information <RmtInf> tag and the additional entry information <AddtlNtryInf> tag as unstructured <Ustrd> data elements supports more remittance details than what is available in the legacy statement formats. This data should be mapped to discrete fields (tags) in order to be used within ERP systems where items like invoices paid, deduction amounts taken or invoices disputed could be used for more effective straight- through processing (STP), auto-matching and auto-reconciliation.

Additional and significant value can be unlocked in the financial supply chain through the expanded and consistent use of ISO 20022 XML message standards for payment processing and statement reporting if all of the parties come into alignment (banks, payment clearing systems, ERP and TMS vendors, middleware vendors, etc.) while also helping support ever expanding regulatory and compliance requirements.

Itron is actively working with its banking partners to migrate from these legacy formats and is willing to share its experiences with others in the hope that there is more uptake in using the camt.xml statement formats. Increase use and demand of these formats will encourage banks and system vendors to further invest in building out enhanced support of the formats and data content.


Reflecting back on the original question around whether ISO XML statement messaging is the right answer, in the case of Itron it has clearly improved and enhanced their existing statement reconciliation processes. However, before embarking on this type of initiative, there are a number of key considerations in order to ensure a more informed decision is made, including:

  • Firstly, what are the challenges and issues you are currently experiencing with your statement reconciliation process and can these be addressed migrating onto XML statement messaging?
  • Understanding the capabilities and potential development options within your own ERP/TMS architecture and the associated availability and cost of appropriate resourcing.
  • What are the capabilities of my banking partners – including how the XML statement is generated and what transaction code options are supported?

Notwithstanding the above, as corporates increasingly focus on achieving greater standardisation and portability, in addition to improving statement reconciliation processes, treasurers and other financial professionals should all expect greater interest in this.


Related reading