CapchaBanking · transaction, ISO 20022 and settlement evidence

The payment is yours. The proof is portable.

CapchaBanking seals the exact bytes of an ISO 20022 message, a settlement leg, or a reconciliation finding into an append-only, cryptographically signed, independently time-anchored record — one your institution, its counterparty, its auditor, or its examiner can verify without trusting CapchaCloud, using published keys and a published method.

Request an evaluation Open the operator console Public chain explorer See a sample Evidence Record

Institutional features are enabled per tenant. Until the banking flag is set for your tenant, the product manifest returns banking_not_enabled rather than a partial surface.

Payment messages, approvals, and supporting documents organized into a single reviewable evidence record. Transaction evidence
One record, checkable by anyone.Message bytes, chain position, and time anchors in a single portable, signed document.
Read this first, because it is the whole shape of the product. CapchaBanking is software: an institutional, never-touch-funds third-party verifier. It attests and proves; it never custodies, settles, or moves funds, and grants no regulated status. Nothing here blocks, holds, releases, returns, or approves a payment in your systems or on any payment rail — no instruction, no hold, no reversal, no clawback, and no recovery originates from CapchaCloud. Every capability here is advisory or evidentiary, and tamper-evident, not tamper-proof. Your institution keeps every decision and remains its own system of record. That paragraph is not marketing framing — the product's own API returns it as a standing honesty_note on the manifest, and each certificate repeats the parts that apply to it.

The evidence exists. It just is not in one place.

For any single payment, the facts that matter are spread across systems that were never designed to agree with each other: the request lives in one channel, the approval in a workflow tool or an inbox, the instruction in a messaging layer, the status report in a network log, and the reconciliation in an end-of-day file. Each system is individually trustworthy and mutually unaware.

Reconstruction is manual

When a payment is disputed, returned, examined, or litigated, someone assembles the story by hand from exports, screenshots, and mailboxes — weeks after the fact, from systems that have each moved on.

The artefacts are only as good as their custodian

A database row, a log line, and a PDF export all share one weakness: they are produced by the party being asked to prove something. Their integrity rests on that party's own controls, which is precisely what is under question.

"It was in the file" is hard to demonstrate

Showing that a specific message existed, in exactly that form, before a specific moment is a different question from showing what a system says today. Most stacks can answer the second and not the first.

CapchaBanking does not replace any of those systems. It sits beside them and produces one thing they do not: a record whose integrity a third party can check independently, at any later date, using published keys and a published method.

How it works

One call per message. No agent to install, no rail to re-plumb, nothing sitting in the payment path.

  1. You send the message, byte for byte. Post the raw XML — the business application header and document envelope exactly as transmitted. The hash is computed over exactly what you send: no trim, no normalization, no re-encoding. That discipline is the entire point, because a hash over a "cleaned up" copy proves something about the copy, not the message. Messages are accepted up to 256 KiB each.
  2. CapchaCloud hashes, indexes, and seals — without needing the message. The default mode is hash_only: CapchaCloud keeps the hash and a small, non-PII index and does not store your message. Storing it is an explicit opt-in (mode: "vaulted") for institutions that want a held copy. A canonical evidence envelope is written to content-addressed, hash-verified storage, where write-once retention applies where the underlying bucket's retention lock is configured.
  3. The record is appended to a chain and independently time-anchored. A single seal takes an immediate RFC 3161 timestamp over the record's own content hash. A tamper-evident audit row is appended, then folded into a hash-linked, Merkle-batched, signed block. Each block hash is submitted to multiple independent RFC 3161 timestamp authorities — DigiCert, Sectigo and FreeTSA — and to multiple OpenTimestamps calendars, which may mature to a Bitcoin attestation asynchronously. If the chain append fails, the response says anchored: false and returns no chain hash. A hash is never fabricated to make a response look clean.
  4. Later, anyone checks it — including people who have never heard of us. Verification and certificate endpoints are public and carry no PII. The record's signed ConsensusFactSet is a single portable JSON file that can be checked entirely offline against the operator public key published at /api/v1/chain/pubkey.

Cryptographic detail, algorithm by algorithm: Crypto inventory · capture and tamper-evidence method: Evidence methodology.

What the evidence record actually contains

The sealed envelope has a fixed key order so its hash is deterministic. These are its real fields, not an illustrative sketch.

message.message_sha256
SHA-256 over the exact bytes received, plus the byte length. This is the field your own systems can recompute against your retained copy.
message.msg_def_idr and message.uetr
The message definition identifier and the unique end-to-end transaction reference, extracted for indexing. Both are nullable, and both are index conveniences — the sealed bytes are authoritative.
message.structure_validation
A pass or fail result plus the specific checks that fired. Well-formedness and message-family structure checking only — never ISO 20022 XSD schema validation. A failure is recorded and never blocks sealing.
handles_hashed
SHA-256 of the business message identifier, group header message id, end-to-end id, sending and receiving agent, and the currency-plus-minor-unit amount. Hashed rather than stored in the clear, so the envelope stays non-PII while still binding those values.
mode
hash_only or vaulted — recorded inside the sealed envelope, so a reader can tell whether CapchaCloud ever held the message.
policy_version
Optional free-text version of the internal policy in force at seal time, so a later reader knows which rules the sealing institution was operating under.
rule_scope
An optional list of regulatory references the tenant itself declares. It ships with a permanent note: these declarations are the tenant's own; CapchaCloud maps no events to regulations and provides no legal advice.
sealed_at, record_id, tenant_id, rail
Server-side seal time, the record identifier, the sealing tenant, and the rail marker.

Alongside the envelope, the record carries its integrity block: the envelope's own content hash, the audit chain hash, RFC 3161 status, and chain inclusion — the block height and Merkle leaf index once the record has been folded into a signed block. Blocks are produced on a daily schedule, and a seal request can ask for one immediately; until then a fresh record is honestly reported as not yet chain-included rather than presented as anchored.

ISO 20022 specifics

The seal path is built for ISO 20022 payment messages — pacs.008, pacs.009, pacs.002, pacs.004, camt.056, pain.001 and their relatives. Any message can be sealed; family-specific structure checks currently exist for pacs.008 and pacs.002, and status corroboration is handled for pacs.002 and pacs.004. Everything else is sealed with the same byte-exact integrity and the generic well-formedness check.

Byte-exact, or it is not evidence

A file upload is sent as its exact bytes with no re-decoding. Pasted or JSON-supplied text is sent as its UTF-8 encoding, still untrimmed. The hash is computed over precisely that. The message is decoded once for indexing and structure checks only — never for hashing.

Extraction is an index, never a claim

UETR, message definition, group header id, end-to-end id, agents and amount are pulled out on a best-effort basis to make records findable. Extraction never fails a seal, and every extracted field can legitimately be null. The bytes remain the authority.

Structure checks, honestly named

Well-formedness plus message-family structure requirements — for example, that a pacs.008 carries a UETR, a group header message id, and an interbank settlement amount. This is not XSD validation and is never described as such. A failed check is recorded on the certificate; the message still seals, because an evidence layer preserves what it received.

Corroboration, with its provenance stated

Submit a pacs.002 or pacs.004 your institution received from its own network and it is matched to an already-sealed record by UETR and sealed through the same pipeline. Provenance is always recorded as bank_submitted: your institution attests it came from its network, and there is no network signature verified by CapchaCloud. The certificate says exactly that.

Batch sealing, with its trade-off stated

Up to 50 messages per call. The batch is not transactional: items are processed sequentially, and a failing item is recorded with its index while the rest continue. Batches default to skipping the per-record RFC 3161 timestamp for throughput; records are still chain-appended and covered by the signed block and its block-level anchors.

Supervisory share links

A scoped, revocable share link can be minted for a specific record. Creation is tenant-authenticated; fetching is token-gated and rate-limited, and every successful access is itself sealed as chain evidence — so the access trail is as verifiable as the record.

What we deliberately do not say. CapchaCloud makes no ISO 20022 conformance, certification, or compliance claim, and does not describe itself as ISO 20022 compliant. It seals evidence about an ISO 20022 message. Exact message-type conformance language is held for standards-body and counsel review before any such statement is made publicly — that gate is recorded in the product's own manifest, not just here.

Operators drive these paths from the ISO 20022 evidence console; the wider institutional bundle lives in the CapchaBanking operator console.

Beyond the message: the rest of the bundle

ISO 20022 sealing is one subsystem. Each of the others carries its own honesty note, quoted here in the same words the product itself uses.

SubsystemWhat it doesWhat it explicitly is not
Settlement evidence log Seals settlement legs — debit, credit, mint, burn, bridge — a window close set, and reconciliation-style comparisons between an expected and an observed side, sealing the finding either way. "Detection and tamper-evident evidence only. Reconciliation, dispute resolution, and any recovery or reversal of funds are the institution's own actions; CapchaCloud performs none of them."
Reserve-adequacy ledger Recomputes an instrument's issued liabilities from a hash-chained event log and compares them against the most recent reserve figure attested by the institution, publishing a signed coverage ratio and status. Not an audit of the reserves themselves, which remain the institution's and its regulators' and auditors' responsibility. Figures are tenant-attested. It confers no deposit insurance, charter, or regulatory approval.
Compliance oracle Records an advisory allow, deny, or review outcome against rules the tenant itself defines, and seals the decision. "Advisory decisions against tenant-defined rules ONLY. Never enforcement, never a compliance verdict, never a regulatory determination."
Independent cosigning Composes already-sealed evidence into one signed certification. Registered external parties can each attach their own Ed25519 signature over the exact factset digest, verifiable against their published keys. A certification with zero cosigners is labelled single-attestor and states that it is explicitly not a federated attestation. CapchaCloud never holds a cosigner's private key and cannot forge a cosignature.
Examiner surface A read-only portal that hands a regulator or auditor the reserve-adequacy state, chain anchors, and offline-verifiable downloads without a login or shared credentials. Not an examination, an approval, or evidence that any examiner has reviewed or endorsed anything.

Related pages: payment-detail drift between authorization and release · the Open Evidence Rail, which makes the same sealing rail format-agnostic for payloads that are not ISO 20022 · examiner portal.

You do not have to trust us — that is the design

This is the strongest thing CapchaBanking can claim, so it is worth being precise about. A sealed record's integrity can be established by a party who has no account, no API key, no relationship with CapchaCloud, and no reason to take our word for anything.

Four independent checks

  • The bytes. Recompute SHA-256 over your own retained message — exact, no trim — and it must equal message_sha256.
  • The envelope. Recompute SHA-256 over the canonical envelope JSON and it must equal the record's vault hash.
  • The position. Re-fold the Merkle inclusion path to the signed block root, confirming the record sits where the chain says it sits.
  • The time. Check the RFC 3161 tokens and the OpenTimestamps proof, which are issued by parties with no relationship to CapchaCloud.

What makes that possible

  • Public endpoints. Verification, certificate, and factset endpoints need no key and carry no PII — safe for an auditor or counterparty to call directly.
  • One portable file. The signed ConsensusFactSet assembles the certificate body, chain head, and anchor status into a single JSON document, Ed25519-signed as a whole, checkable offline against the published key.
  • Published keys. The operator public key and its rotation history are published for anyone to fetch.
  • Signatures are never invented. If no signing key is configured, a factset is returned honestly as signed: false with an explanation, rather than carrying a fabricated signature.

To check the ledger itself rather than one record, a dependency-free script walks every block from genesis to the current tip over the public read API, recomputes every block hash, and verifies the operator's Ed25519 signature. 

curl -O "https://capchacloud.com/verify-capchachain.mjs"
node verify-capchachain.mjs https://capchacloud.com

Under the chain: SHA-256 Merkle batching with explicit domain separation between leaf and interior nodes, an Ed25519 block signature required at every height, and — from a recorded cutover height onward — an additive ML-DSA-65 post-quantum co-signature that must also verify. The layers are AND-composed, never OR-composed: a block signed by both is invalid if either signature fails, and there is no "any one signature is good enough" fallback anywhere in the stack.

Browse real blocks and anchors: public chain explorer · live anchor status: /api/v1/transparency · algorithm detail: crypto inventory.

Integration

Tenant-authenticated calls carry your API key as Authorization: Bearer <key>. Verification and certificate calls are public: no key, no PII, safe for any auditor to call directly.

Seal a message

curl -X POST "https://capchacloud.com/api/v1/iso20022/seal" \
  -H "Authorization: Bearer $CAPCHACLOUD_API_KEY" \
  -H "Content-Type: application/xml" \
  --data-binary @pacs008.xml

# Response includes: record_id, message_sha256, vault_hash, chain_hash,
# anchored, tsa_status, block_height, mode, verify_url, certificate_url

Sending the file with --data-binary is deliberate: the bytes on the wire are the bytes that get hashed. A JSON body of the form { "message_xml": "…" } is also accepted and is encoded as UTF-8 without trimming.

Verify it — no key required

curl "https://capchacloud.com/api/v1/iso20022/verify?record_id=isoev_<uuid>"
curl "https://capchacloud.com/api/v1/iso20022/isoev_<uuid>/certificate"
curl "https://capchacloud.com/api/v1/iso20022/isoev_<uuid>/factset"
EndpointAuthPurpose
POST /api/v1/iso20022/sealTenant keySeal one message, byte-exact.
POST /api/v1/iso20022/seal-batchTenant keySeal up to 50 messages; not transactional.
POST /api/v1/iso20022/corroborateTenant keyAttach a bank-submitted pacs.002 or pacs.004 status report.
GET /api/v1/iso20022/recordsTenant keyList this tenant's sealed records, keyset paginated.
POST /api/v1/iso20022/{id}/shareTenant keyMint a scoped, revocable supervisory share link.
GET /api/v1/iso20022/verify?record_id=PublicIntegrity verification with a plain-language how-to-verify block.
GET /api/v1/iso20022/{id}/certificatePublicCertificate stating what it proves and what it does not.
GET /api/v1/iso20022/{id}/factsetPublicSigned, independently recomputable ConsensusFactSet.
POST /api/v1/settlement/legTenant keySeal a settlement leg.
POST /api/v1/settlement/reconcile-checkTenant keyRecord and seal an evidentiary reconciliation comparison.
GET /api/v1/settlement/verify?record_id=PublicPublic verification of a settlement leg or discrepancy record.
GET /api/v1/bankingTenant keyProduct manifest: every subsystem, endpoint, and honesty note.
GET /api/v1/chain/pubkeyPublicOperator public key for offline signature verification.

General API conventions: API reference.

Pricing

Priced in credits, not per seat and not per user. Credits come from one subscription and pool across every CapchaCloud product.

ISO 20022 sealed message

10 credits
Approximately $0.05 per sealed message. Each message inside a batch is priced the same as a single seal.

One credit

≈ $0.005
Pegged to the cheapest action across the platform. Monthly plan credits are spent first; prepaid pack credits never expire.

Institutional features

Enterprise
Cosigning, oracle corroboration, and custom settlement evidence sit in the Enterprise plan. Usage still just draws credits — there is no separate platform-fee line.

Full plans, credit allowances, and the per-action cost table: pricing.

What a record proves, and what it does not

Every certificate CapchaCloud issues carries an explicit does_not_prove statement, because a record that overstates itself is worse than no record at all. The same discipline applies to this page.

What it proves

  • These exact message bytes existed, unaltered, at or before the sealed and anchored time.
  • The record is sealed into an append-only, cryptographically signed ledger and independently time-anchored — RFC 3161 immediately, Bitcoin and OpenTimestamps maturing asynchronously.
  • Any third party can verify byte integrity and chain inclusion offline, without trusting CapchaCloud or the sealing institution.
  • Where a status message was corroborated: that a related network message referencing the same UETR was submitted by the institution and separately sealed.

What it does not prove

  • It does not move or hold funds. CapchaCloud never custodies, settles, transmits, or moves money, and never touches a payment rail.
  • It does not block or approve a payment. No hold, release, reversal, clawback, or recovery originates here. Those are your institution's actions.
  • It does not prove settlement finality. That determination belongs to the payment rail's or financial market infrastructure's own legal domain, not to this evidence layer.
  • It does not prove payment authorization. A sealed record does not establish that the underlying payment was authorized.
  • It does not determine intent. A discrepancy is a discrepancy. It does not establish fraud, fault, or bad faith — an error and a deliberate alteration look identical to a comparison.
  • It does not guarantee fraud prevention. No control does. A message altered before it was sealed, or moved through a channel outside the sealed workflow, is outside what a seal can speak to.
  • It does not prove the contents are correct or true. Structure checking is well-formedness and message-family checking only, never XSD validation and never a claim about semantic correctness. CapchaCloud seals exactly what it received.
  • It does not deliver any compliance verdict or regulatory outcome. It makes no statement about sanctions screening, AML or KYC outcomes, or regulatory compliance for the underlying payment. It is evidence infrastructure, not legal advice, not a compliance determination, and not a regulatory approval.
  • It does not replace your existing controls or systems of record. Your core, your sanctions screening, your risk analytics, and your reconciliation all still do jobs this does not do. Removing any of them because of this would be a mistake.
  • Timestamp witnesses are not certifications. Independent timestamp authorities and external anchoring establish that a hash existed at a point in time. They are not a government certification, a regulatory approval, or an endorsement.

Where we honestly are

Your diligence will surface all of this. You should hear it from us first.

How the platform runs

Described in capability terms. The third parties that process data on our behalf are named in full in the Subprocessors Policy — we publish that list rather than obscure it, and it is the right document for your vendor-risk team.

Delivery and resilience

  • Edge-native, globally distributed. Verification runs close to the requester across a globally distributed network rather than in one distant data centre. No traditional private network, no virtual machines, no exposed ports.
  • No single-region dependency. Compute is stateless with no persistent local state, which removes entire classes of server-compromise risk.
  • Redundant storage. Object storage with built-in redundancy across multiple physical locations, plus regular backups of production databases.
  • Anchoring survives an outage. A timestamp-authority outage does not stop a block from sealing or rewrite a sealed record; a scheduled sweep retries missing witnesses, and the public anchor endpoint lists which witnesses actually exist for a block.

Data handling

  • Write-once retention applies where the underlying storage bucket's retention lock is configured — the storage layer then prevents modification, overwrite, or deletion before the lock expires. We do not claim a hash chain alone is operator-proof WORM hardware.
  • Content-addressed, hash-verified evidence storage with application-level retention controls that can be audited separately.
  • Encryption. TLS 1.2 minimum and TLS 1.3 preferred in transit; AES-256 at rest across primary data stores.
  • Tenant isolation by construction — per-tenant data isolation, per-tenant origin allowlists, and per-tenant API keys, with keys stored hashed.
  • Message retention is your choice. Default hash_only sealing means CapchaCloud never holds the message at all.

Full detail: Trust Center · Security overview · Data residency · Data Processing Addendum

Questions your diligence team will ask

Does CapchaBanking move, hold, or custody funds?

No. CapchaBanking is software: an institutional, never-touch-funds third-party verifier. It attests and proves; it never custodies, settles, or moves funds, and grants no regulated status. That sentence is returned by the product's own API manifest, not just written on this page.

Does CapchaBanking block, hold, or approve a payment?

No. Nothing here reaches into a payment rail, a core banking system, or a settlement process. It seals evidence of what a message said and when it existed. Your institution keeps every decision to send, hold, return, or investigate.

Is a sealed record a claim that the payment settled?

No. Every certificate states explicitly that it does not prove settlement finality — that determination belongs to the payment rail's or financial market infrastructure's own legal domain, not to this evidence layer. It also does not prove payment authorization.

Can we verify a record without trusting CapchaCloud?

Yes, and that is the point. Recompute SHA-256 over your own retained message bytes and compare it to message_sha256. Fetch the record's signed ConsensusFactSet — one portable JSON file — and check its Ed25519 signature against the operator public key published at /api/v1/chain/pubkey. Independently re-fold the Merkle inclusion path to the signed block. A published, dependency-free script walks the whole append-only chain from genesis and re-checks every block signature.

Does CapchaCloud need to store our payment messages?

No. The default sealing mode is hash_only: the hash and a small non-PII index are retained and the message itself is not stored by CapchaCloud. Storing the message is an explicit per-request opt-in (mode: "vaulted") for institutions that want CapchaCloud to hold a copy.

Is this an ISO 20022 validator or a conformance certification?

No. The structure check is well-formedness and message-family structure checking only — never ISO 20022 XSD schema validation, and never a claim about semantic correctness. A failed check is recorded on the record; it never blocks sealing, because an evidence layer preserves what it received. CapchaCloud makes no ISO 20022 conformance or compliance claim.

What does a status corroboration actually establish?

That your institution submitted a related network message — a pacs.002 or pacs.004 carrying the same UETR — and attests it came from its own network. Provenance is always recorded as bank_submitted. There is no network signature verified by CapchaCloud on a corroboration, and the certificate says so in those words.

Does CapchaBanking hold a SOC 2, ISO 27001, or PCI certification?

No. CapchaCloud is pre-certification for its own SOC 2 Type II report and holds no ISO 27001 or PCI certification of its own. It relies on its infrastructure and payment subprocessors' compliance postures plus its own documented safeguards. Current status is published in the Trust Center.

What does an ISO 20022 seal cost?

Ten credits per sealed message, charged the same way for each message inside a batch. One credit is approximately $0.005, so a sealed message is roughly $0.05. Credits come from one subscription and pool across every CapchaCloud product. See pricing.

Can we evaluate this without touching production?

Yes. The ISO 20022 console and the CapchaBanking console exercise the real endpoints against a tenant of your own, and every public verification endpoint can be called from outside your environment entirely. Nothing about an evaluation requires a change to a payment path.

What happens if the chain append fails?

The response returns anchored: false and no chain hash. A hash is never fabricated to make a response look complete, and a partially-sealed result is reported as partial rather than presented as success.

Start with an evaluation, not a purchase

Bring a handful of representative messages, seal them into your own tenant, then hand the record identifiers to someone on your team who has no CapchaCloud account and ask them to verify the records independently. If that does not work, nothing else on this page matters.

Request an evaluation Operator console Public chain explorer Sample Evidence Record

Or email support@serviceautomations.ai with a clear subject line. Procurement and vendor-risk questions: Trust Center, DPA summary, and the full Data Processing Addendum.

ISO 20022 console · CapchaBanking console · Open Evidence Rail · Payment-detail drift · Chain explorer · Pricing