Structured On-Chain Memos: Reconciling Blockchain with ISO 20022

TL;DR

• A blockchain “memo” is a free-text note attached to a transaction. For institutional payments it is a dead end, because it carries no structured, validated data and cannot be matched to a bank’s records.
• Reconciliation means matching a payment to its record in the accounting and compliance systems a bank already runs. ISO 20022 structured data is what lets an on-chain transaction reconcile this way, making it a prerequisite for institutional adoption.
• Banks have moved from an older messaging format (MT) to the ISO 20022 format (MX). This SWIFT coexistence period ended November 22, 2025, so cross-border payment instructions must now use the ISO 20022 MX format.
• Validating data can happen off-chain, inside a smart contract, or through an attestation layer, and no approach today delivers full ISO 20022 on-chain enforcement.
• Arc, Circle’s EVM blockchain is testing onchain memos that could be a step in the right direction for adoption.
• Three problems stay open: the cost of storing text-rich messages on-chain, the confidentiality risk of putting PII on a public ledger under frameworks such as GDPR, and the absence of a settled standard for encoding the data. 

The Reconciliation Problem

Banks, corporates, and payment providers run on ISO 20022 messaging, the global standard now supporting the main payment networks. These include 

• SWIFT (the network banks use for cross-border transfers), 
• SEPA (euro payments across Europe),
• Fedwire (large-value transfers in the United States), 
• and other RTGS systems, the real-time gross settlement networks that move high-value interbank payments.

SWIFT ran two message formats side by side for years: the older MT format and the newer ISO 20022 format, known as MX. 

This overlap, called the coexistence period, ended November 22, 2025. After that date, cross-border payment instructions must use the ISO 20022 MX format.

In that world, every payment carries structured, validated fields. These include remittance information (a note explaining what the payment is for), debtor and creditor identifiers (who pays and who is paid), purpose codes, and end-to-end IDs, all machine-readable and governed by a fixed schema.

An on-chain memo is an arbitrary string, or nothing at all. It cannot populate those fields, which breaks the logic banks depend on: automated matching of payments to records, compliance screening, and straight-through processing (STP), the hands-free movement of a payment from start to finish.

2026 is widely positioned as an inflection point for ISO 20022, because end-to-end structured data enables automation and real-time reconciliation. On-chain settlement that cannot speak this language stays outside institutional systems.

What Institutions Require in a Payment Message

The core design principle of ISO 20022 is that data is preserved end-to-end. A payment moves through three stages, and the data is delivered without loss: initiation, when a company instructs its bank to pay (a pain.001 message); the interbank leg, when banks move the funds between each other (a pacs.008 message); and reporting, when the bank tells the account holder what happened (a camt message).

The elements that drive reconciliation each serve a specific function, as the table below lists.

Element	What it does
End-to-End Identification (EndToEndId)	The customer-assigned reference, passed unchanged along the whole chain, that lets the beneficiary tie the payment back to its originating instruction.
UETR	A separate 36-character UUID v4 tracking reference, mandatory in value messages such as pacs.008, that identifies the transaction bank-to-bank.
Structured Remittance Information (RmtInf)	Invoice numbers, creditor references, and referred-document data. Distinct from the legacy 140-character unstructured free-text field.
Purpose Code / Category Purpose	Codes the transaction’s economic rationale for compliance and routing.
Ultimate Debtor / Ultimate Creditor	The parties on whose behalf the payment moves, beyond the immediate account holders.
Party identifiers	The LEI (Legal Entity Identifier, a global company ID), the BIC (Bank Identifier Code, which names the bank), and a structured postal address. Together these form the backbone of sanctions screening.

In banking, when a payment converts from the initiation message (pain) to the interbank message (pacs), fields the beneficiary needs are sometimes dropped or shortened. An on-chain memo is perceived similarly, carrying almost no structured fields at all.

What a Structured On-Chain Memo Carries

The same fields a bank payment message carries can be encoded on-chain, so the transaction can be reconstructed as a payment record. Two worked examples render the concept.

Example A: A Corporate Credit Transfer

A corporate credit transfer moves funds from one company to another to pay an invoice. A structured payload attaches the payment’s context to the on-chain event, and each field lines up with a named field in the ISO 20022 standard, as the table below shows.

On-chain field	ISO 20022 field	What it is
EndToEndId	EndToEndId in pain.001 / pacs.008	The reference tying the payment to its instruction
UETR	dedicated UETR element	The bank-to-bank tracking reference
Invoice reference	RmtInf/Strd/RfrdDocInf	The structured note of what is being paid
Purpose code	Purp/Cd	Why the payment is being made
Ultimate parties	UltmtDbtr / UltmtCdtr	Who the payment is ultimately for
LEI	OrgId/LEI	The company identifier for screening

With these fields present, the on-chain event is reconstructable as a payment record. A treasury system can match it to the originating instruction and the invoice automatically.

Worked Example B: A Tokenized-Asset Settlement

A tokenized-asset settlement, also called RWA (real-world asset) settlement, moves a tokenized asset such as a bond or fund unit that has been issued as a token. It needs a structured remittance block that identifies the instrument being traded.

The structured remittance carries an asset reference inside a field called Referred Document Information, and an asset identifier such as an ISIN (International Securities Identification Number, the standard code for a stock or bond) can accompany it. The category purpose is set to SECU, the ISO 20022 code that flags the payment as a tokenized asset transaction, and a free-text memo carries none of this.

Contrast: The Same Transaction With a Bare Memo

The same transaction carried by a bare memo loses nearly all of its context, as the table below shows.

Information	Structured memo	Bare memo
End-to-end reference	Present as EndToEndId	Absent or unparseable
Invoice or an asset identifier	Present in structured RmtInf	Free text at best, often missing
Purpose of payment	Coded (Purp/Cd, SECU)	Not present
Ultimate parties	Named in dedicated fields	Not present
Party identifiers (LEI, BIC)	Structured and screenable	Not present
Reconstructable as a payment record	Yes	No

A Live Implementation: Arc Transaction Memos

Arc, a blockchain from Circle, moved a version of the structured-memo concept into testnet on June 18, 2026. Its transaction memos attach structured context (an invoice ID, a payout reference, or an internal ledger key) to individual contract calls without modifying the underlying contract, including the USDC transfer contract.

The design targets the reconciliation break: the memo emits as an on-chain event only when the underlying call succeeds, preserves the original sender, and carries across both single and batch transactions. A payment service provider can tag every transfer in a batch with its own payout reference, and a bank can pass internal identifiers through settlement without inventing custom transaction types.

Even though Arc memos are not ISO 20022-native, Circle does not claim schema conformance or on-chain validation for them. They show the structured-memo pattern moving from concept to shipping infrastructure, while the encoding-standard and validation questions this article raises remain open.

How the Data Gets Validated

Validation of an ISO 20022 payload means checking it against schemas, format rules, and official code lists before it is trusted. Validation here covers three distinct checks:

1. Schema conformance against the XSD or JSON schema, the official blueprint that defines which fields a message must contain and in what order.
2. Field format rules, verifying that identifiers are well-formed. This covers the IBAN (International Bank Account Number), the BIC, and the LEI, plus character-set restrictions and control sums (check digits that catch typos).
3. Code-list checks, confirming that purpose codes and charge-bearer codes match the official ISO code lists.

A message failing any of these is rejected before settlement, the same way SWIFT issues a NAK (a negative acknowledgement) for a non-conforming message.

Validation can happen in three places, each with a different tradeoff.

Placement	Strengths	Limitations
Off-chain, pre-submission	Cheapest and fully expressive, with full XSD validation	The assurance lives outside the ledger; the chain trusts that validation occurred
In a smart contract	On-chain enforcement and composability, so other contracts can build on it	Gas (the fee paid to run code on-chain) and size limits make full-schema validation impractical; typically only format, presence, and hash checks
Attestation / oracle layer	Balances expressiveness and on-chain verifiability	Reintroduces a trusted party, the attester itself

An oracle is a service that brings outside data onto a blockchain. In the attestation model it checks the payment data off-chain, then posts a signed confirmation on-chain that the check passed. This echoes a SWIFT–Chainlink pilot: in 2025, working with UBS Tokenize, the Chainlink Runtime Environment (CRE) turned confirmed outputs into ISO 20022 messages and delivered them through SWIFT, while Chainlink‘s cross-chain protocol (CCIP) copied those records across blockchains.

No option today gives both full ISO 20022 expressiveness and trustless on-chain enforcement, so institutions accept one constraint or the other.

Why Unstructured Memos Fall Short for Institutional Settlement

Unstructured memos fail institutional requirements on four counts:

1. No schema enforcement. Nothing constrains or validates the string, so malformed data settles unchecked.
2. No machine-readability. No reliable parse into party, purpose, or reference fields exists, so screening and matching revert to manual work.
3. No reliable link between the on-chain event and the off-ledger payment record, which is the reconciliation break itself.
4. Downstream cost. Manual reconciliation, higher rejection and repair rates at on-ramps and off-ramps (the services that convert between traditional money and crypto), compliance friction, and audit records where the movement of funds cannot be reconstructed end-to-end. For a bank processing thousands of settlements, these costs compound with volume.

The Open Problems

Three open problems remain unresolved, and careful institutional planning accounts for all of them.

Size and Cost

Carrying a full ISO 20022 message on-chain is expensive and often impractical. These messages are written in XML, a verbose text format, and under CBPR+ (the SWIFT rulebook for cross-border payments) the remittance data alone can run to thousands of characters. Blockchain storage is scarce and costly, which discourages putting complete messages on-chain.

Sensitive Data on a Public Ledger

Party identifiers and remittance detail are personally identifiable information (PII). Placing them on a public ledger raises open questions under frameworks such as GDPR that call for legal review.

Three design options address confidentiality, each with a tradeoff:

1. Hashing. Commit a hash on-chain and keep the data off-chain, giving verifiability without exposing the content.
2. Selective disclosure. Reveal specific fields only to authorized parties.
3. Off-chain payload with an on-chain reference. Store the message off-chain and post only a pointer on-chain.

Each option trades verifiability against confidentiality, and none removes the tension entirely.

No Settled Encoding Standard

No agreed standard defines how ISO 20022 data should live inside a blockchain transaction. Competing approaches put the data in native fields, in calldata (the input attached to a transaction), or off-chain with only a pointer stored on-chain.

Adjacent standards add context, such as the Digital Token Identifier (ISO 24165), a code that uniquely names a specific token. 

A chain supporting ISO 20022 potentially removes a technical barrier, opening wider access for blockchain technology adoption through multiple use cases like RWAs, stablecoins and other financial instruments.

Where Everstake Fits

Everstake operates non-custodial validator infrastructure for institutions that need reconcilable, audit-ready on-chain activity. Non-custodial means the asset owner keeps control of their own keys while Everstake runs the validators. Founded in 2018, Everstake has historically operated 130+ Proof-of-Stake networks and holds SOC 2 Type II, ISO/IEC 27001:2022, and NIST CSF certifications, with GDPR and CCPA alignment.

Everstake tracks how structured messaging standards intersect with the chains institutions evaluate for settlement. Its institutional staking service integrates with custody platforms such as Fireblocks, BitGo, and Anchorage Digital, and it frames the structured-memo question as one input into a broader diligence checklist, alongside validator reliability, compliance posture, and operational support through its validator services.

FAQ

What is ISO 20022 and why is it relevant to blockchain?

ISO 20022 is the global standard for structured financial messaging, mandatory for SWIFT cross-border payments since November 22, 2025. It is relevant to blockchain because on-chain settlement that cannot carry ISO 20022 data cannot reconcile with the bank systems institutions already run.

Can an on-chain memo carry ISO 20022 data?

Yes. A structured on-chain memo can carry ISO 20022 fields such as EndToEndId, structured remittance information, purpose codes, and LEI identifiers, so the on-chain event can be rebuilt as a full payment record. This is why non-custodial providers such as Everstake track structured messaging for the chains institutions evaluate.

Should payment data go on a public blockchain?

Party identifiers and remittance detail are PII, so placing them on a public ledger raises questions under frameworks such as GDPR that require legal review. Options such as hashing, selective disclosure, and off-chain storage with an on-chain pointer each trade verifiability against confidentiality.

Does a chain supporting ISO 20022 mean institutions will use it?

No. Supporting ISO 20022 removes a technical barrier without producing institutional use on its own, since adoption also depends on validation approach, confidentiality handling, and cost. Operational support from certified providers such as Everstake, holding SOC 2 Type II and ISO/IEC 27001:2022 across its 130+ networks, is part of that diligence.

Disclaimer

This article discusses compliance-adjacent topics as analysis and options. It is not legal advice. Legal review is required before relying on any specific compliance assertion.