The Future of Cross-Border Compliance

Cross-border financial compliance is built on a paradox. The regulations exist to protect people — their identities, their assets, their privacy. But the compliance mechanisms designed to enforce those regulations do the opposite: they require sensitive personal data to be copied, transmitted, stored, and processed by institutions the customer has never heard of, in jurisdictions the customer may never visit, under data protection regimes the customer cannot influence.

This paradox has persisted for decades because there was no alternative. To verify compliance, you had to see the data. To see the data, the data had to travel. To travel, it had to be replicated. The chain of custody was the chain of exposure.

That era is ending. The mathematics now exist to prove compliance without transmitting the underlying data. The question is no longer whether this is possible. It is whether financial institutions and regulators will adopt it before the next systemic breach forces the issue.

The Current State: Full-Payload Transmission

Today, cross-border compliance works through full-payload transmission. When a financial institution sends a payment across borders, the compliance data travels with it — or ahead of it. The originator's identity details, the beneficiary's identity details, the transaction metadata, the risk indicators, the source of funds documentation — all of it is transmitted to intermediaries, correspondent banks, compliance utilities, and ultimately the beneficiary's institution.

Each entity in this chain performs its own compliance checks. Each entity stores the data for its own regulatory retention period. Each entity becomes a custodian of data it did not collect, from customers it does not serve, under regulations it may not fully understand.

The scale is staggering. SWIFT processes over 45 million messages per day. Each message carrying cross-border payment data creates multiple copies across multiple jurisdictions. Correspondent banking networks amplify this further — a single payment may touch four or five institutions before reaching the beneficiary. The global financial system maintains billions of redundant copies of sensitive customer data, not because any single regulation requires it, but because the architecture demands it.

Three Regulatory Frameworks, One Problem

The three dominant regulatory frameworks governing cross-border financial transfers each contribute to the full-payload problem, but none of them actually require it.

FATF Recommendation 16: The Travel Rule

FATF Recommendation 16, commonly known as the travel rule, requires that originator and beneficiary information "travel" with the wire transfer. The recommendation specifies that the originator's name, account number, and address (or national identity number, or date and place of birth) must accompany the transfer. For the beneficiary, the name and account number are required.

Read carefully, Recommendation 16 requires that this information be available to the beneficiary's institution and to competent authorities. It does not specify the mechanism. It does not require that every intermediary in the chain have access to the raw data. It requires that the information exist and be verifiable. A cryptographic proof that the originator's identity was verified against the required fields — accompanied by the specific fields the beneficiary institution needs — satisfies the recommendation. The intermediaries need only verify the proof.

EU Transfer of Funds Regulation

The EU Transfer of Funds Regulation (Regulation 2015/847, as amended) implements the FATF travel rule within the European Economic Area and extends it with additional requirements around verification. Article 4 requires the payment service provider of the payer to ensure that the transfer is accompanied by specific payer information. Article 7 requires intermediary payment service providers to retain all information received with the transfer.

The regulation's Article 7 requirement is often cited as mandating full-payload transmission to intermediaries. However, the regulation requires intermediaries to retain the information "received" — if what they receive is a cryptographic proof rather than raw data, they retain the proof. The regulation does not specify that the information must be in plaintext. It specifies that it must be available for regulatory inspection. A verifiable proof, accompanied by a mechanism for regulatory authorities to access the underlying data from the originating institution when needed, satisfies this requirement while dramatically reducing the intermediary's data exposure.

US Bank Secrecy Act and AML Requirements

The US Bank Secrecy Act and its implementing regulations under 31 CFR Chapter X require financial institutions to maintain records of funds transfers of $3,000 or more and to include specific transmittal order information. The recordkeeping requirements are detailed but, again, do not mandate that every institution in the chain hold the raw data in plaintext.

FinCEN's enforcement actions focus on whether institutions performed adequate due diligence, maintained appropriate records, and filed required reports. The mechanism of recordkeeping — whether plaintext data or cryptographic proofs with verifiable attestations — is not prescribed. What matters is that the institution can demonstrate compliance when examined.

The Proof-Based Alternative

The alternative to full-payload compliance is proof-based compliance: send what the law requires, prove everything else. This is not a theoretical concept. The cryptographic primitives are deployed and operational. H33-Wire-Proof implements this model for international wire transfers today.

The model works as follows. The originating institution performs all required compliance checks — sanctions screening, beneficiary verification, jurisdiction analysis, risk scoring, source of funds assessment — on the raw data within its own systems. Each check produces a cryptographic proof: a signed, timestamped attestation that the check was performed, that the specific regulatory requirement was evaluated, and that the result was either pass or fail.

These proofs are assembled alongside the legally required plaintext fields — typically the transaction amount, currency, value date, and the specific originator and beneficiary fields mandated by the receiving jurisdiction. The assembled message is transmitted through the normal wire transfer infrastructure. Intermediaries receive the proofs and the minimal plaintext. They verify the proofs. They do not need — and do not receive — the full payload.

The proofs are policy-bound. Each proof specifies which regulatory requirement it satisfies. A sanctions screening proof references the specific sanctions list version, the screening algorithm parameters, and the timestamp of execution. A jurisdiction check proof references the specific regulatory framework, the jurisdiction classification, and the risk assessment criteria applied. The proofs are not generic attestations of compliance. They are specific, auditable, verifiable records of exact compliance actions.

H33-74 Attestation: The Cryptographic Anchor

Every compliance proof generated through H33-Wire-Proof is attested by H33-74, our 74-byte post-quantum attestation system. This attestation binds the proof to a specific point in time, a specific compliance event, and a specific set of cryptographic commitments.

The attestation uses three independent post-quantum signature families, each based on a distinct hardness assumption. Forging an attestation requires breaking all three simultaneously — lattice-based problems, structured-lattice problems, and hash-based constructions. This is not redundancy for its own sake. It is a direct response to the regulatory reality that compliance records must remain valid for years, often exceeding the projected timeline for cryptographically relevant quantum computers.

A compliance proof attested by H33-74 today will remain verifiable and tamper-evident in 2033, 2040, and beyond. The same cannot be said for compliance proofs signed with RSA or ECDSA, which are the signatures underpinning virtually all current financial compliance systems.

What Minimal Disclosure Looks Like

To make the concept concrete, consider a $250,000 wire transfer from a US bank to a bank in Singapore, routed through a correspondent bank in London.

Under the current model, the correspondent bank in London receives the full MT103 message: originator name, address, account number, national identifier, beneficiary name, account number, bank identifier, purpose of payment, regulatory reporting codes, and dozens of additional fields. The London correspondent performs its own sanctions screening on the raw data, stores the full payload for five years under UK regulatory requirements, and forwards the complete message to Singapore.

Under the proof-based model, the correspondent bank in London receives: the transaction amount ($250,000), the currency (USD), the value date, a settlement reference, and a set of cryptographic proofs. The proofs attest that the originator passed OFAC sanctions screening (with the specific list version and timestamp), that the beneficiary passed UK and Singapore sanctions screening, that the corridor risk assessment was performed and the result was within acceptable parameters, and that the originator's identity was verified to FATF Recommendation 16 standards.

The London correspondent verifies the proofs. This takes milliseconds. It stores the proofs — compact cryptographic data, not personal information — for its regulatory retention period. It forwards the proofs and minimal plaintext to Singapore. At no point does the London correspondent store, process, or have access to the originator's name, address, national identifier, or any other personal data field.

If a regulator examines the London correspondent's records, the proofs are available. If the regulator needs access to the underlying data — for a specific investigation, under proper legal authority — it requests that data from the originating US bank, which holds it under its own data protection and regulatory framework. The chain of custody is clear. The chain of exposure is minimal.

The Regulatory Acceptance Path

Regulators are not obstacles to proof-based compliance. They are, increasingly, advocates for it. The European Data Protection Board has repeatedly emphasized the principle of data minimization in financial services. The FATF's own guidance on new technologies acknowledges that technological solutions can satisfy compliance requirements without replicating traditional data-sharing patterns. FinCEN's innovation programs explicitly encourage approaches that reduce unnecessary data exposure while maintaining compliance effectiveness.

The path to regulatory acceptance follows three stages. First, demonstration: proving that the cryptographic proofs satisfy the specific requirements of each regulation. Second, parallel operation: running proof-based compliance alongside traditional full-payload compliance to verify equivalence. Third, transition: moving to proof-based compliance as the primary mode, with traditional full-payload available as a fallback for exceptional circumstances.

H33 is currently engaged in the first and second stages with multiple financial institutions across three jurisdictions. The results consistently show that proof-based compliance meets or exceeds the compliance outcomes of traditional full-payload approaches, with dramatically reduced data exposure and processing overhead.

Addressing the Objections

Will Regulators Accept Proofs Instead of Data?

Regulators already accept proofs instead of data in numerous contexts. Digital signatures are proofs of identity. Hash chains are proofs of integrity. Timestamps are proofs of existence. The specific application to compliance — proving that a sanctions check was performed without sharing the screened data — is a natural extension of cryptographic verification that regulators already understand and accept. The regulatory question is not whether proofs are acceptable in principle. It is whether specific proof implementations satisfy specific regulatory requirements. That is an engineering problem, not a policy problem.

What About Investigations and Law Enforcement?

Law enforcement access to financial data is essential and is not diminished by proof-based compliance. The underlying data still exists at the originating institution. Law enforcement requests — subpoenas, production orders, mutual legal assistance treaty requests — are directed to the institution that holds the data, under the legal authority of the jurisdiction where the data resides. This is actually a cleaner legal framework than the current model, where the same data exists in multiple jurisdictions under multiple legal regimes, creating jurisdictional conflicts over access and production obligations.

What About Real-Time Screening by Intermediaries?

Some intermediaries perform real-time sanctions screening on wire traffic as it passes through their systems. This screening currently requires raw data access. Under the proof-based model, the originating institution's screening is the primary check, and the proof attests to its execution. If an intermediary's policies require independent screening, the FHE-based approach allows it: the intermediary receives encrypted data, performs screening on the ciphertext, and produces its own proof — without ever seeing the plaintext. Both models are supported. The choice depends on the intermediary's risk appetite and regulatory requirements.

The Timeline

Cross-border compliance will not change overnight. The infrastructure is deeply embedded, the regulatory frameworks are jurisdiction-specific, and the institutional inertia is significant. But the direction is clear.

ISO 20022 migration, which is currently underway across all major payment systems, provides a natural integration point for proof-based compliance. The richer data structures of ISO 20022 can accommodate cryptographic proofs alongside or in place of traditional data fields. SWIFT's Transaction Manager, designed to orchestrate ISO 20022 payments, could be extended to handle proof verification as a standard processing step.

The institutions that adopt proof-based compliance early will have structural advantages: lower data breach risk, less expensive compliance operations, simpler cross-border data protection compliance, and the ability to demonstrate to regulators and customers alike that they handle data with the minimum exposure necessary. The institutions that wait will eventually be compelled by regulation, by competitive pressure, or by breach — but they will adopt it regardless, because the mathematics do not care about institutional timelines. Once proof-based compliance exists, full-payload compliance becomes an unnecessary risk that someone will eventually refuse to accept.

Send What the Law Requires. Prove Everything Else.

The future of cross-border compliance is not more data. It is more proof. Not more sharing. More verification. Not more copies of sensitive information scattered across the global financial system. Fewer copies, bounded by legal necessity, anchored by mathematics.

FATF Recommendation 16 is satisfied. The EU Transfer of Funds Regulation is satisfied. The US Bank Secrecy Act is satisfied. The data protection regulations — GDPR, PDPA, LGPD, PIPA — are not just satisfied but actively advanced, because data minimization is no longer aspirational. It is operational.

The wire still settles. The compliance still happens. The regulation still works. But the data exposure drops by 89%, the breach surface collapses, and the proof is independently verifiable by any party with the verification key — regulator, auditor, counterparty, or court.

This is not a future we are imagining. It is a future we are building, transaction by transaction, proof by proof, institution by institution.