Global Billing Statements: The Wild, Wild West

The international bank billing arena has been dubbed the ‘wild, wild west’ in the past. Commercial bank pricing and account analysis statements are hard enough to understand in the US alone, but companies with international banking relationships quickly learn that ‘anything goes’ globally. Some banks, especially US-based ones, adhere to a detailed fee-based approach to compensation, while European banks are paid using float.

A corporate treasurers trying to understand and budget for bank fees is left befuddled when assessing what they actually pay their international banks for. The grim reality is that:

• Accurately verifying international bank fees and volumes is next to impossible.
• Bank fee analysis is labour-intensive.
• Lacking detail, corporate treasurers cannot provide management with global bank relationship metrics.
• International cash management fees are decentralised with few controls in place.
• Lack of controls and transparency create compliance issues.

With the bank services billing (BSB) format soon to be released under the ISO 20022 umbrella and the release of the Association for Financial Professionals’ (AFP) global service codes (GSCs), banks from around the world have made history by working together to create a common language for bank billing. Has law and order truly been established in the wild west?

The Standardised Solution

In the US, over 800 mid-large sized corporations receive bank analysis statements electronically using the American National Standards Institute (ANSI) X12 EDI 822 transaction set. These electronic statements are downloaded into software, either purchased off-the-shelf or developed in-house, and manipulated to generate reports, cross-check volumes and prices, and ultimately eliminate the paper/manual aspect of account analysis.

Elsewhere, there hasn’t been a standard electronic format for bank billing. Members of the Transaction Workflow Innovation Standards Team (TWIST), prompted by multinationals like General Electric (GE), formed a panel of experts to create a standardised extensible markup language (XML) billing format for global use to try to rectify this.

“Rather than trying to expand the existing EDI 822 format governed by ANSI, the consensus was for a new standard in the universal XML language,” says TWIST member Paul Burstein, former managing director, strategic initiatives of GE Treasury, and a key player in the BSB development. “The ultimate goal is to have the BSB standards included under the ISO 20022 umbrella with electronic bank account management (eBAM) and other corporate/banking messages. The BSB ISO 20022 standard are in the final stages and will be available to the public any day.”

Ultimately, the BSB is best described and understood in the US as the 822 for global corporations. This chart outlines the differences between the two and where the new AFP GSCs fit in.

Figure 1: The Differences Between AFP GSCs and BSB

Source: The Montauk Group

The codes were developed in 1986 to enable corporate treasurers to compare apples-to-apples when reviewing commercial banking services. A standardised code also allows corporations to generate reports and track volumes and prices electronically, which is virtually impossible with a textual description.

New AFP GSCs

A number of banks, with TWIST’s support, approached the AFP to consider either expanding their existing codes to accommodate global bank services or develop a completely new set of codes they could use within the BSB file. After lengthy review, a new set seemed the only logical choice. Even simple terminology differences made an extension of existing US codes problematic.

The ability to ‘scratch and start over’ gave the AFP more flexibility in terminology and depth, to make the codes easier to understand globally and simpler to maintain. One problem with the current US codes is the update process; codes are not added unless a panel of corporations and banks first agree, which takes time.

Conversely, codes are not removed from the master list unless there is absolutely no way they could be used. If just one person still uses microfiche, the code stays in. This leads to an ever-growing list of codes in the book. Keeping the AFP GSCs high-level, and therefore easier to maintain, was a key driver during development.

Intended Users

The AFP GSCs were designed for use with the BSB, just as US domestic codes were designed for the ANSI 822. Of course banks can choose to provide the codes to their clients upon request, even if they are sending the statements in Excel or PDF format.

Just because a bank may perform many international services for a customer, such as international wires, multicurrency accounts or payments/receipts in foreign currencies, doesn’t mean the customer should start asking for the AFP GSCs.
The codes were intended for two types of corporation:

• Multinationals such as GE with operations in the US, Europe, Asia, and/or elsewhere.
• Corporations of all sizes with operations outside the US, and one or more banking relationship.

The first targeted corporation, accustomed to getting ANSI 822s in the US, also wants to receive electronic statements, AFP coded, in overseas offices from their foreign banks to consolidate all information worldwide in their centralised treasury. The second has never received an EDI 822, and is happy to finally start receiving their bank bills in a standard format they can use and manipulate.

The Code Structure

The AFP GSCs consist of eight digits. The first three digits are alpha and represent the product family; the remaining five are numeric. For example, ACT00000 is the AFP global code for account maintenance. AFP domestic codes are six alphanumeric digits; so the AFP code for DDA account maintenance is 010000.

“We wanted the codes to look very different from the original, to further identify them as a completely separate set,” said Tom Hunt, the AFP’s director of treasury services. “The alpha product family makes it easy to identify if there is an error in the coding. ‘LBX’ is easily recognised as ‘lockbox’ and more user-friendly than the current domestic product family for lockbox services ‘05’.”

Banks are developing two separate streams within their analysis system. If a customer is set up to receive an ANSI 822, then the domestic codes are already there and nothing changes. If the customer wants a BSB file, the bank analysis would pull the global codes into the BSB file. The two should not be displayed at the same time. Banks are encouraged to further identify the service by also including their own bank service ID.

Within the ISO BSB standard, AFP global code usage will be coded as AFP GBL, while use of the domestic codes will simply be coded as AFP. No balance reporting codes exist in the AFP GSC set. XML enumerations are used to report balance and compensations totals in the BSB.

A mapping tool is provided by the AFP, with subscription to the codes, to link the line items together where there is a parallel between AFP domestic and AFP global services codes. ‘010000 DDA account maintenance’ is the same service as ‘ACT00000 account maintenance’ in the global codes. The mapping tells the software developer to pull from both where there is a direct match, and is key to the software providers gearing up to receive both 822 and BSB files and pulling both line items into reports for customers.

Steve Weiland, founder of Weiland Financial Group (now part of Open Solutions), was a key participant in developing the BSB and the AFP GSCs. He says: “Two major enhancements to global electronic billing are now in place. The new AFP GSCs allow a multinational to track services like prices and taxes across all the banks they deal with. The new ISO 20022 BSB standard provides an international stamp of approval and on-going standard maintenance. Taken together, these two enhancements will invite many more global banks into the electronic billing arena, much to the pleasure of their customers.”

As to system defaults, the BSB file does not require an AFP code. The field is optional. In the case where a global code doesn’t exist you can leave it blank, or apply the same logic used domestically for customised services by getting as close to the real code as possible and adding 9 at the end.

Banks should always avoid using all 9s as a code (xxx-99999), having fallen into the habit of assigning insufficient codes (such as 999999 or false codes) as placeholders in the ANSI transaction set. The placeholders became permanent and the integrity and use of the codes has suffered.

For those concerned about the proper assignment of the codes to their service line items, AFP offers the accredited service code provider program for both sets of service codes. Banks may submit their services to the AFP for assignment and management. Major global banks have more than 4,000 service line items to review and code between their different platforms worldwide. Consistency within the same bank is a big enough challenge, when those services may be named very different things in Asia and Europe. The latter region also has the added complication of single euro payments area (SEPA) compliance.

With high turnover and resource constraints, it is difficult for a bank to devote the time and expertise required to assign all the codes properly and consistently. Outsourcing the task to AFP solves that problem. Additionally, as an AFP service codes accredited provider banks’ service codes are reviewed on a yearly basis, instead of assigned and then forgotten about. Subsequent versions of the codes are automatically updated for accredited providers as well.

Ultimately, corporate treasurers need to know what commercial banking services their bank provides and the cost. Providing this information on a paper statement is no longer a viable option, especially when dealing with global operations. Downloading 60 pages of account activity in a PDF format that a treasurer must sift through and manually enter into a workstation, or account analysis software, is annoyingly cumbersome and ultimately bad for a bank relationship.

When billing a client, it is important not to add heartache to an already painful experience. By implementing the BSB and the AFP GSCs, banks can offer treasurers a tool to make their jobs easier. It would be no surprise if, in the near future, request for proposals (RFPs) conducted overseas include the AFP GSCs, as many are already doing in the US with domestic codes, although there are of course other competitors. Corporations can also use the codes to provide a standardised list of services they require and have banks bid accordingly.

The benefits don’t end there.  Many commercial solutions providers are excited about the AFP GSCs as well. For example, The Montauk Group uses the codes internally to help compare bank services and pricing as a part of their BankScore global bank fees and rates index.

The ultimate goal of tying standardised codes to the multitude of bank services available is to increase understanding and order in an otherwise wild world. It has been a privilege to work with banks around the world to make this vision a reality.

Comments are closed.