CapchaCloud ISO 20022 Message Evidence Certificate · schema iso20022-cert-1.0.0
ISO 20022 Message Evidence Certificate
Record isoev_b5dcf9e8-f244-46b8-85e2-537e614c18eb · sealed 2026-07-02T03:41:01.518Z
Message
| MsgDefIdr | pacs.008.001.08 |
|---|
| UETR | 3f29a7c4-8b1e-4d6a-9c52-1e7f0a6d4b83 |
|---|
| Mode | vaulted |
|---|
Integrity
| Vault hash (SHA-256) | 7176c2c4b0a1a662dab3a37ec8c651694bc34ba02782307e062402b3859af45e |
|---|
| Message hash (SHA-256) | 34917f084de637d80b047706d4baf70e23fb4c3eeda7c85118c828d7f282053e |
|---|
| Chain hash | 86f88a34c03bc28068c0184d746b1c49d422fe2fad0d790524d65668e1e8fbed |
|---|
| Anchored | yes |
|---|
| TSA status | anchored |
|---|
| Chain inclusion | included in block #57 |
|---|
Structure validation
| Result | pass |
|---|
| Checks | (none — passed) |
|---|
| Note | Well-formedness and message-family structure checks only — not ISO 20022 XSD schema validation. |
|---|
Corroboration
The bank submitted a related network message (pacs.002/pacs.004) attesting receipt from its own network. This is a bank attestation, not a verified network signature.
| MsgDefIdr | TxSts | Provenance | At (UTC) |
|---|
| pacs.002.001.10 | ACSC | bank_submitted | 2026-07-02T02:50:07.477Z |
| pacs.002.001.10 | ACSC | bank_submitted | 2026-07-02T03:38:15.566Z |
| pacs.002.001.10 | ACSC | bank_submitted | 2026-07-02T03:41:02.681Z |
| pacs.002.001.10 | ACSC | bank_submitted | 2026-07-02T05:16:26.984Z |
| pacs.002.001.10 | ACSC | bank_submitted | 2026-07-02T06:16:35.373Z |
What this proves
- These exact message bytes existed, unaltered, at or before the sealed/anchored time (content-addressed by message_sha256; the envelope binding it is content-addressed by vault_hash).
- The record is sealed into an append-only, cryptographically-signed ledger and independently time-anchored (RFC-3161 immediate; Bitcoin/OpenTimestamps matures asynchronously).
- Any third party can verify byte-integrity and chain inclusion OFFLINE, without trusting CapchaCloud or the sealing bank.
- A related network message (e.g. a pacs.002 status report) referencing the same UETR was submitted by the bank and separately sealed — see corroboration.events.
What this does NOT prove
- Settlement finality — that determination belongs to the payment rail's / financial market infrastructure's own legal domain, not to this evidence layer.
- Payment authorization — this record does not establish that the underlying payment was authorized.
- Correctness of message contents beyond structure checks — structure_validation is well-formedness and message-family structure checking only, never ISO 20022 XSD schema validation, and never a claim about semantic correctness.
- Any compliance verdict — this certificate makes no statement about sanctions screening, AML/KYC, or regulatory compliance outcomes for the underlying payment.
- Corroboration here means the bank submitted a related network message and attests it came from its network — provenance is 'bank_submitted'; there is NO network signature verified by CapchaCloud for this corroboration.