FedNow – the Federal Reserve’s new instant payment service – went live earlier this summer, and it could signal big changes ahead for B2B payments. Why? It comes down to data. B2B payments are rife with data challenges.

In my last post, I described that the funds transfer component of a B2B transaction is often easier than the exchange of purchase, invoice, and remittance information associated with the payment. Orders are renegotiated, clerks make incorrect entries in AR and AP tools, and goods are damaged, all contributing to the “data mysteries” that perplex corporate back offices and stymie reconciliation processes.

Digitization, automation, and machine learning all help buyers and suppliers do a better job of communicating and parsing transaction-related information, but what would happen if the industry decided to rethink the way it communicates in the first place?

That’s the idea behind ISO 20022 (“twenty-oh-twenty-two,” if you want to sound like an expert), a messaging standard for financial transactions. And it’s not just an idea: ISO 20022 is a core component of many new payments systems, such as FedNow, and is making its way into existing payment systems as well. Let’s explore what it solves for, what its limitations are, and what the future could hold.

ISO 20022 in B2B

In the context of B2B transactions, ISO 20022 implementation addresses two common issues: the lack of native remittance data handling capabilities in payment systems, and the lack of consistency in remittance data.

Remittance Data Handling

We can explain that with an example, starting with that first data handling issue. I often like to use the example of an egg wholesaler selling to a grocer to break down B2B challenges in simple terms. In this scenario, imagine that a grocer purchased 1,200 eggs from the wholesaler but found that 120 (or 10%) of the eggs were broken on delivery. Thus, they only pay 90% of their invoiced amount. In order to reconcile their accounts receivable, the wholesaler must receive an explanation for this. But if the grocer pays them via ACH, for example, there is limited space to add information describing the transaction and why it differs from the expected amount (we call that sort of data about data “metadata”). 

Since the metadata often travels separately from the payment in an email or as a PDF attachment, the wholesaler has to intervene in the flow and do some manual work to extract necessary information into their AR module. At Glenbrook we (wryly) observe that checks remain popular in the B2B context because of their data handling capabilities: you can stuff the remittance documentation in the envelope with the check. In payment systems that support ISO 20022 messaging, however, there is space for rich metadata. This means that the 10% adjustment the grocer is taking can be explained directly in the payment itself, in a machine-readable manner.

Consistency in Remittance Data

But native data handling alone is not enough to facilitate machine-to-machine readability. Machines need to be able to pick up information from a predictable location (i.e., from the payment, as opposed to in an email inbox or somewhere else) but also in a predictable format. That’s what we mean by consistency in remittance data. The grocer’s message explaining the discrepancy between the original invoice and the ultimate payment amount should probably include a number of data elements: the invoice number, an indication that an adjustment has been made, the amount of the adjustment, and a reason for the adjustment. In order to help a receiving system to ingest these data elements, ISO 20022 specifies names for these data elements. 

That means that when a system receives an ISO 20022-formatted message it knows exactly where to look for the information it expects to receive. That is to say, it knows that it can look for a message alongside the payment, and that it can look for a data element explaining the adjustment (for example) within this message. That means that it will be more likely for the transaction to be completed without human intervention. We call the sort of scenario in which data is processed without human intervention “straight through processing.” Straight through processing doesn’t require ISO 20022, but it helps in scenarios like the egg wholesaler example; without structured data, reconciling the payment with the open invoice would likely require (in a relatively happy scenario) manually lining up remittance and payment information or (in a worse scenario) a lengthy back and forth between egg wholesaler and grocer to understand the nature of the difference.

Implementing Solutions

That’s great news for corporate finance teams. Manual, repetitive tasks are error-prone and costly in terms of employee hours that could be directed toward higher-impact activities. Naturally, we’re excited about ISO 20022 and payment systems like FedNow that include the support for the standard. But we’re also not pollyannaish about the likelihood of ISO 20022 as a panacea that solves all of the B2B space’s problems. Implementing corporate-facing solutions that support ISO 20022-formatted messaging requires bank support for both the standard and the payment method that uses it. Just as importantly, it also requires corporate end users to change their payment habits, something that finance teams are generally slow to do. Still, we see ISO 20022 adoption as a compelling trend alongside automation and machine learning that, with some patience on our part, could lead to a world of smoother B2B transactions. 

In the meantime, it’s an exciting time to be a fintech, bank, or corporate practitioner thinking through how ISO 20022, new payments rails, and tools can help give them a competitive edge. If that’s you, let’s talk!