Earlier this week I wrote about DeepInfer and the shape of the answer. Batch-invariant inference, deterministic sampling, and output constrained to a JSON schema or grammar now ship together in the open. Valid JSON is table stakes. The hard part is agreeing on the shape. Payments and banking is the industry where I expected that part to be easiest, because the shapes have been written down for a long time. So I went and looked.
The answer this industry needs
The business outcomes here are not abstract. A finance team gets a PDF invoice and needs a valid credit transfer instruction. A supplier sends a remittance email and someone has to match it to a line on a bank statement. A customer writes three angry paragraphs about a charge and an operations team has to turn that into a structured dispute.
Turn an invoice into a payment instruction. Turn a remittance note into a reconciliation entry. Turn a narrative into a case a bank system will accept. Every one of those ends in a message that a bank, a network, or a ledger will reject outright if one field is wrong. Nobody in this industry wants a creative answer. They want the same correct answer every time.
The shape is already written down
ISO 20022 is the shape for money movement. The message names are the vocabulary practitioners already use: pain.001 for a customer credit transfer initiation, pacs.008 for the interbank credit transfer, pacs.002 for payment status, and the camt family for cash management and statements. I could not load iso20022.org from here today (it returned a 403), so I am leaning on how these names show up in the providers’ own contracts, which I did read.
On the account data side, there are several regional shapes. FDX in the United States. The Berlin Group NextGenPSD2 framework in Europe. The UK Open Banking Standard. Australia’s Consumer Data Standards under the Consumer Data Right. Each one names the accounts, balances, transactions and payment consents a compliant API has to return.
The APIs.io standards page shows how many catalog providers carry each as a tag:
- ISO 20022: 20 providers
- FDX: 13 providers
- Consumer Data Standards: 30 providers
- Open Banking Standard: 40 providers
- NACHA: 53 providers
- Berlin Group NextGenPSD2 and the UK Open Banking Standard entries: no provider tagged yet
There is also a profile for each in the API Evangelist standards catalog, including ISO 20022 and FDX.
What the catalog holds
I used three cohorts from the Markets layer: payments, open banking, and US open banking (FDX). The payments cohort is 25 providers with a mean Kin Score of 69.1. Stripe leads at 81.1, then Uphold at 79.2 and Square at 78.1. The open banking cohort is 24 providers with a mean of 63.4, led by Plaid at 84.6, then IBANforge at 72.0 and Token.io at 71.6.
The US open banking cohort is the story. It is 25 providers with a mean of 38.4. Plaid is at the top again at 84.6, MX at 65.4 and Citi at 61.4. Then it falls off. Chase is at 33.4, Capital One 32.0, PNC 10.6, Fidelity 7.8, and The Clearing House 13.1. The aggregators that sit between banks and apps score well. Most of the banks whose data is being shared score thin or below in what they publish publicly. Agent readiness tells the same story, with Capital One, American Express and USAA at 3.1 and PNC and Fidelity at 0.
Across the 70 distinct providers in those three cohorts, I counted artifact folders in their repos: 53 have JSON Schema, 57 have vocabularies, 47 have AsyncAPI, 17 have examples, 15 have JSON Structure, and 8 have Arazzo workflows. A good share of those schemas and vocabularies are API Evangelist’s own derived work, not something the provider published, so read the counts as what the catalog holds, not what the industry ships.
The part that matters is the provider-published contracts that name ISO 20022 messages directly. Citi’s original OpenAPI files reference pain.001.001.03 and pacs.008.001.08. Barclays publishes a file payments contract built on pain.001.001.08. SoFi’s payment hub contract talks about pacs.008 or pacs.004 messages being published to the network and awaiting a pacs.002 status. Currencycloud and Truist (BB&T) reference pacs.008 in their own contracts too. That is the shape of the answer, already sitting inside the OpenAPI a model would be asked to call.
What determinism changes here
Payments are reconciled, audited and regulated. Every one of those properties assumes that the same input gives the same output.
If a model turns an invoice into a pain.001 today and a slightly different one on Friday because another request landed in the same batch, the reconciliation breaks and nobody can explain why. Batch-invariant inference removes that. Deterministic sampling means an auditor can rerun the same invoice through the same model and get the same instruction, which is the closest thing to a reproducible decision this industry will accept from a model. Constrained output means the model cannot invent a currency code, a purpose code, or a status that the scheme does not define, because the vocabulary is the grammar.
Volume matters too. Banks process these messages by the million. A structured answer that comes back valid 99 percent of the time is a queue of exceptions somebody has to work by hand. A structured answer that can only be produced in the schema’s shape moves the remaining errors from formatting into meaning, which is where a human reviewer should be spending time anyway.
Where it falls short
The standards exist. The publishing does not keep up. Berlin Group NextGenPSD2 and the UK Open Banking Standard have no provider tagged in the catalog yet, even though I can see Berlin Group references in several provider repos. That is a tagging gap on our side. The bigger gap is that the large US banks named in the FDX cohort mostly do not have a public FDX contract I can find. The shape is defined, but it sits behind partner agreements and aggregators rather than in a public OpenAPI.
ISO 20022 is published as XML schemas from the registration authority. Most providers who use it describe it in prose or embed XML examples in a JSON API. A few schemas in the catalog, from BB&T, Atlar and Banco Inter, mention pacs.008 in their fields or descriptions, but I could not find one that is a JSON Schema of the message itself that a constrained decoder could consume directly. That translation is still left to every team.
I left card network dispute and reason codes out of this post entirely. I could not source them from a public machine-readable place today, and I am not going to guess at them.
The close
Payments is the industry that should benefit first from constrained, deterministic inference, because it already did the hard work of agreeing on the shape decades ago. What is missing is the last step: the banks and networks publishing those shapes as machine-readable contracts where a model, and the people governing it, can find them. The aggregators have done it. The fintechs have mostly done it. I would like to see the banks do it too, because the answer is only as good as the shape you hand the model.
