Post-Quantum Migration Architecture & Interbank Settlement Rails

1. The High-Throughput Interbank Settlement Landscape

Global interbank settlement systems operate under the most stringent availability requirements in software engineering: 99.999% uptime, zero message loss, deterministic ordering, and sub-second clearing.

Every payment message traversing SWIFT, the Federal Reserve's Fedwire Funds Service, the Clearing House Interbank Payments System (CHIPS), or the Eurosystem's TARGET2 requires cryptographic non-repudiation:

• Origin Authentication: Verifying that the sending financial institution strictly authorized the debit instruction.
• Payload Integrity: Ensuring that beneficiary account numbers, IBANs, amounts, and currency codes have not been altered in transit.
• Non-Repudiation: Guaranteeing that neither counterparty can contest the legal validity of the settlement event before central bank clearing authorities.

2. The Cryptographic Anatomy of ISO 20022 Payloads

An ISO 20022 financial message comprises a Business Application Header (`head.001.001.03`) and a Document Body (such as `pacs.008.001.10` for customer credit transfers):

<!-- Simplified ISO 20022 pacs.008 Payload with Cryptographic Envelope -->
<BusinessMessageEnvelope xmlns="urn:iso:std:iso:20022:tech:xsd:head.001.001.03">
  <AppHdr>
    <Fr><FIId><FinInstnId><BICFI>HSBCGB2LXXX</BICFI></FinInstnId></FIId></Fr>
    <To><FIId><FinInstnId><BICFI>BARCGB22XXX</BICFI></FinInstnId></FIId></To>
    <BizMsgIdr>B20260928-98421092</BizMsgIdr>
    <MsgDefIdr>pacs.008.001.10</MsgDefIdr>
    <CreDt>2026-09-28T09:14:00Z</CreDt>
  </AppHdr>
  <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.10">
    <FIToFICstmrCdtTrf>
      <GrpHdr><MsgId>HSBC-20260928-001</MsgId></GrpHdr>
      <CdtTrfTxInf>
        <IntrBkSttlmAmt Ccy="EUR">15000000.00</IntrBkSttlmAmt>
      </CdtTrfTxInf>
    </FIToFICstmrCdtTrf>
  </Document>
  <!-- Cryptographic Security Header -->
  <Sgntr>
    <!-- Classical ECDSA + Post-Quantum ML-DSA-65 Dual Signature -->
  </Sgntr>
</BusinessMessageEnvelope>

3. The Signature Size Dilemma: Managing 3.3 KB ML-DSA Signatures

In classical payment engineering, digital signatures represent a negligible fraction of the message footprint: an ECDSA P-256 signature occupies 64 bytes. In contrast, NIST FIPS 204 ML-DSA-65 signatures require 3,309 bytes.

If attached directly to individual micro-messages, this creates severe network operational complications:

• TCP Packet Fragmentation: Standard Ethernet maximum transmission units (MTU) are 1,500 bytes. A 3.3 KB signature forces a single ISO 20022 message across three IP packets, multiplying packet loss probabilities and triggering reassembly delays on high-speed gateway interfaces.
• Database Bloat in Settlement Archives: Processing 50 million transactions daily increases annual storage requirements by over 60 terabytes purely for signature metadata.
• Memory Allocation Overhead in Message Parsers: Ingestion pipelines parsing XML schemas in memory experience garbage collection pressure when decoding massive base64-encoded signature blocks.

4. The Backwards-Compatible Dual-Signature Envelope Format

To allow gradual interbank adoption where some clearing member banks support PQC while legacy members have not yet updated their gateway nodes, Crypto Service specifies a Dual-Signature Envelope:

<Sgntr xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
    <Reference URI="#Document">
      <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
      <DigestValue>...classical digest...</DigestValue>
    </Reference>
  </SignedInfo>
  <SignatureValue>...classical 64-byte ECDSA signature...</SignatureValue>
<!-- Post-Quantum Extension Object (FIPS 204) -->
<Object Id="PQCExtension">
<PQCSignature Algorithm="urn:nist:fips:204:ml-dsa-65">
<KeyId>HSBC-PQC-KEY-2026-V1</KeyId>
<SignatureValue>...3309-byte base64 encoded ML-DSA-65 signature...</SignatureValue>
</PQCSignature>
</Object>
</Sgntr>

Legacy payment gateways verify the standard classical signature and safely ignore the unrecognized `Object` element. Modern quantum-safe gateways verify both signatures, achieving immediate non-repudiation against CRQC adversaries.

5. Verification Throughput & Latency SLAs

Settlement engines must verify many signatures per second within tight SLAs, so verification cost matters. @sebastienrousseau/crypto-lib verifies ML-DSA signatures one at a time in JavaScript through @noble/post-quantum. It has no batch verification, no WebAssembly or SIMD acceleration, and no published latency figures; earlier figures in this section (a 4.2x SIMD speedup, 68.4 µs per signature) did not come from committed code and have been withdrawn.

Before committing to an SLA, benchmark verification on your target hardware (see benchmarks/crypto-bench.ts in the repository) and scale verification horizontally across processes or workers as needed.

6. Rail-by-Rail Migration Strategy

7. Summary & Implementation Roadmap

Core banking architects must begin integrating post-quantum signature verification modules into test harnesses today. Waiting for scheme operators to mandate hard deadlines will result in costly emergency refactoring under regulatory pressure.