Unfortunately for companies looking to implement this new bank-reporting standard, a simple search for information about CAMT053 yields limited results. Most published information consists of bank implementation guides and a limited set of case studies. Very little information is available on how a company can make the leap from a standard to an actual technology implementation, or on what corporate treasurers should know to adequately prepare for a successful implementation of CAMT053 in collaboration with their banking partners.

What Can CAMT053 Accomplish?

Figure 1, below, shows the nesting structure of the CAMT053 standard. By using this standard for interactions with its banks, a company can greatly reduce the risk of miscommunication and greatly increase the proportion of transactions that reconcile automatically between its bank statements and its transactional systems, particularly when coupled with XML payment files. It can also more easily pull data from multiple banks' statements into a single database for comparison and analysis.

That said, standards cannot guarantee that an organization will achieve universal consistency among all its business partners, for all transaction types and all data. When considering, and then implementing, technology that supports CAMT053, corporate treasurers need to keep in mind that the standard is simply that: a standard. Standards do not demand consistent adoption by all parties.

CAMT053 uses a schema, which enforces certain rules and establishes a structure for all the data tags that the bank's statements will include, the types of values allowed within each data field, etc.

The purpose of implementing standards is to reduce variability in data. If every organization you do business with must fit its data about your transactions into a narrowly defined standard, then the data will be comparable across organizations and across your internal processes. You will be better equipped to analyze internal efficiency and to compare the performance of different vendors, customers, etc. However, the downside of using narrowly defined data standards is that some companies, and some transactions, will not fit neatly into the definition.

The CAMT053 standard offers extensibility; it supports the inherent variability of transactions across the world. However, its usage cannot correct problems in the underlying transaction flow or add data that was not included as part of the original payment data. Consider this accounts receivable example: Clearing and automatically posting payment receipts is a goal for many companies' A/R departments, but achieving this goal requires the customer to include remittance information identifying each individual invoice. If a customer does not remit its invoice information as part of its payments, there is no way to automatically reconcile this activity as part of bank statement processing. Simply switching formats, from a BAI2 or MT940 to a CAMT053, cannot correct this problem, as necessary information was never submitted with the original payment.

How Does CAMT053 Work?

Each transaction that appears on a bank statement in the CAMT053 format has three identifiers: Domain, Code, and SubFamilyCode. For the sake of illustration, we will consider an outgoing SEPA payment and an incoming SEPA receipt. Showing these transactions will clarify how the XML structure works in practice.

Our first transaction, an outgoing SEPA credit transfer, is contained in Figure 1, below. The Domain code is the highest-level identifier; it indicates the broad category that a transaction falls into. An initiated SEPA payment, for example, would fall under the Payments domain, as labeled by XML tag "PMNT." Within the Payments domain, data can be labeled with any of an assortment of Code tags, which provide an additional level of detail for identifying the type of payment. Our SEPA payment, for example, might be labeled as an Issued Credit Transfer, identified by XML tag "ICDT." Finally, the SubFamilyCode identifier provides the lowest-level definition for the payment. Our example might have the SubFamilyCode SEPA Credit Transfer, which uses the "ESCT" data tag. Figure 1 also shows the End to End ID that will accompany the payment as it moves from organization to organization.

Comparing Figure 1 with Figure 2 shows the difference between payments that are issued by a company and the collections it receives. An initiated SEPA receipt, for example, would still fall under the Payments domain, as labeled by XML tag "PMNT." The differentiation occurs within the Code tag. Here a received credit transfer would be indicated by "RCDT." The subfamily identifying the SEPA payment would be labeled "ESCT," the same as if it were an outgoing payment.

Getting Ready for CAMT053

A corporate treasurer whose transaction banks are capable of managing data in the CAMT053 format should look closely at the company's systems and processes to determine how the organizational infrastructure would need to change in order to take advantage of the new format, and whether shifting to CAMT053 makes sense. Answering these three questions is a good way to get started:

1. How can our treasury management system or ERP system process CAMT053 statements?

A natural lag occurs between the release of a new banking standard and its initial adoption by customers. This is normal for two reasons. First, banks must build systems and/or processes to generate files that comply with the new standards. And second, once the banks are capable of generating files in the new format, vendors of the software used by banking customers—in other words, treasury management system and ERP providers—must develop the functionality to communicate with banking systems that use the new format.

From a technical perspective, it's possible for ERP and treasury management system providers to revamp their software before representative files are available. However, this work would be difficult to justify before the vendor could accurately gauge customer demand, especially considering that software developed too early would likely require changes down the road. In an environment where software providers must develop functionality to support regulatory and accounting changes, providers need compelling reasons to expand their products' functionality. Banks' development activities and implementation of standards can provide software vendors with leading indicators on customers' potential adoption.

Companies whose software vendors already support CAMT053 functionality must understand how their system supports the standard. Typically, CAMT053 formats would simply be added to existing functionality by the provider to allow for reading bank statements in the new format. One of the simplest ways to know if this base functionality is available is by looking at the processes involved in loading and posting statements today. During setup, users generally must select the formats the system will use for processing statements. And looking to see whether the CAMT053 format is an option in your system can help you understand your starting point.

If you are rolling out a new payment system, and you select the CAMT053 statement format for processing transactions, then you should expect to spend extra time on testing processes due to the learning curve for the new standard. Allow plenty of time for working with your banking partners to address questions on the CAMT053 layouts.

If you are implementing the new statement format with a banking partner with which you already have live accounts and transaction information, ask your bank to generate CAMT053 statements that mirror the information you are already receiving today in other formats. This will enable you to learn what information you should expect to receive in the new formats before you implement them. It will also provide an opportunity to work out any potential kinks or errors that may arise either within your banking partner's systems or your ERP systems.

If, on the other hand, you are implementing the standards with a new banking partner, you'll face some special challenges. Few banks have the capability to provide detailed testing files for accounts that are not live. They may provide sample files, but these will not account for all transactions and will not contain data pertaining to your company. Some financial institutions can generate a bank statement for testing based upon your payment files—but many cannot. When working with new clients, banks generally build sophisticated systems to thoroughly test their new payment infrastructure, but they generally do not build the same robustness into testing of bank statement processes directly with their customers. With this in mind, allow for extra time in the transition so that you can make changes in your systems once you see how the bank will send all the information on its statements.

As a practical example, the End to End ID that XML-enabled systems can generate for outgoing payments lets a single ID number follow a transaction from customer to supplier to payment-processing banks. Using such an identifier can enable higher rates of automated transaction clearing, as it helps ensure that all parties to a transaction are on the same page about which invoice or purchase order the payment should be associated with. Taking advantage of this functionality in order to improve automated bank statement clearing does require a company to have payments settle individually, as opposed to batch settlement. This is necessary to receive back the individual transaction details. But for many companies, this approach is worthwhile because of how much faster and easier it makes reconciliation.

In a traditional batch settlement process, many payments can be sent, but one or more payments may fail. Sometimes it is easy to identify failed payments by amounts, but for the bank account reconciler, it can often be difficult to identify which payment or combination of payments failed. The reconciler needs to know which payment is which in order to complete the bank statement clearing and reconciliation of individual items to the batch total on the statement. In switching from batch-settled to individually settled payments, the End to End ID will tell you exactly which line items are associated with payments that settled properly. The system can then automatically clear those in-transit items, leaving the bank account reconciler to manage only the exceptions. For companies with a large volume of payments, this can significantly reduce the reconciliation time for payment clearing.

2. How would global standardization be inhibited by differences inherent in local payment-clearing systems?

SEPA makes significant strides toward standardization of transaction identifiers. However, any strategy to globally implement CAMT053 statements must consider the differences between SEPA and non-SEPA countries.

One example is in the area of returned payments. SEPA payment systems provide for specific data tags to identify returned payments. But domestic clearing systems or cross-border systems in other regions may not have consistent identifiers; returned funds may actually be labeled as a receipt or incoming funds transfer. It really depends upon the information included by the bank returning the payment. When returned payments are marked with different identifiers in different geographic regions, that discrepancy could impact the company's cash application to customer accounts. A returned payment that looks like a receipt of funds may end up as a reconciling item during the bank statement reconciliation process. This isn't necessarily a limitation of the company's banking partner; it may instead be a limitation of how the information was provided to the bank.

So, what does this mean for you? These transactions may require special manual post-reconciliation processing in your systems. They may fall into a queue for an accounts receivable processor, where instead they should move to the queue for an accounts payable reversal. It's up to the treasurer to outline both standard and exception processes during the implementation of the system using the CAMT053 standard.

Before moving to CAMT053, make sure you understand how variability among payment-clearing systems in the different geographic regions in which your company operates may influence your organization's ability to automate transaction reconciliation processes. For example, does your bank receive all clearing information for domestic transfers from all local clearing systems? If not, you may need a custom solution or custom functionality in order to automatically apply receipts to clear all non-disputed customer invoices.

3. How does our banking structure affect our ability to standardize? 

Most organizations have relationships with several banks. A corporate treasurer needs to understand how information flows, both within each of the company's banking partners and across its banking relationships, in order to simplify implementation of the CAMT053 standard.

Each of a company's banking partners has different underlying software systems. The first thing the treasurer needs to understand is how the organization's banking partners will use CAMT053 to create XML-based statements. Will a bank's legacy systems generate an MT940, then map it into an XML statement? Or will the bank's systems natively generate CAMT053-compliant statements? Customers of banks whose systems map XML from an MT940 may find their ability to standardize their XML layout is limited because the legacy systems aren't all collecting the same underlying data. Information that passes between systems in its native XML format may be tagged more consistently in the XML file.

Partner-bank arrangements, forwarding agreements, or aggregators can add more layers of complexity. Many companies have regional banking partners but rely on other banks in countries where none of their banking partners has a presence. These arrangements can simplify the complexity for payments design, but also must consider the implications on bank reconciliation design. There are a variety of different technical structures to facilitate and support transaction flow, and each partner bank arrangement has different levels of technical integrations.

For partner-bank arrangements, the questions to ask are similar to those around how legacy systems generate statements. Ask how the partner-bank integration actually works from a data and mapping perspective. Partner-bank integrations may occur at different levels: Some banks may integrate by simply passing an MT940 from the partner bank to the regional bank, whereas other banks build deeper integrations that preserve the full payment detail and transaction flow of the CAMT053 statement. Agreements that rely on the former structure may limit customers' ability to receive detailed transaction identification simply due to the limitations in the MT940 format.

Selecting a Banking Partner for CAMT053

For companies that are considering a move to CAMT053 bank statements, the most important action item is to discuss the following questions with your banking partners prior to starting your formal project.

• Do you map your CAMT053 statements from an existing format, such as BAI2 or MT940, or are they generated natively based on the original transactions?
• Are all statements generated out of a central system, or do you use country-based systems for the formats? Is there any chance we could experience a slight variability in the identification data between different transactions due to how your internal systems interact?
• Are the statements that are generated on online platforms identical to those that will be transmitted through automated transmissions?
• For your partner banks, what level of detail is sent on the originating payments through the integrated systems? Will we lose any remittance information or originating transaction details?
• Do you have the option to provide individual line-item detail for all payments we originate, so that we can use the End to End ID to aid in our reconciliations?
• Please describe any limitations or special capabilities you have around returned payments.
• In cases where you have MT940 forwarding arrangements with other banks, are there any special capabilities to allow for more detailed transaction identification, or will we experience limitations in the data we receive?
• Do you receive all available remittance information for payments, for all countries, from the clearing systems? (Corporate treasuries should review at a country-by-country level to ensure you understand where there might be limitations due to country clearing systems or limitations based on the bank's infrastructure.)
• For foreign exchange payment transactions, the CAMT053 standard provides the ability to add details information on transaction amounts, FX rates, etc. To what level will you populate FX transaction information so that we can perform automatic clearing in our systems?
• Please explain what level of detail we will receive about fees, and how this ties into account analysis reporting.
• How do you manage system upgrades or mapping changes for new releases in your infrastructure? Can changes be run in parallel, or must we adopt all changes immediately?

Getting detailed answers to these questions will help you understand what you might achieve through a CAMT053 implementation, and where you may run into challenges. It will also help ensure that you have adequate information to plan a successful implementation.

Amber Christian is the founder of ConsultAce, an SAP A/P, A/R, treasury, and cash management implementation firm. She is a frequent speaker and writer on a variety of topics in the treasury space. She also hosts the podcast "Thriving at the Crossroads," where real business problems meet real solutions.