Network Working Group L.J. Reilly Internet-Draft REM Technologies & Consulting, LLC Intended status: Standards Track 3 September 2026 Expires: 7 March 2027 Reilly Banking Integrity Protocol (RBIP) draft-reilly-banking-integrity-02 Abstract This document defines version 02 of the Reilly Banking Integrity Protocol (RBIP), a compliance-grade architecture for generating immutable, auditor- and regulator-verifiable evidence trails in banking operations. RBIP combines cryptographic anchoring (via a public timestamping service) with archival deposit under a persistent identifier to produce permanent, tamper-evident records across three compliance domains: Proof-of-Reserves & Liquidity (PRL), Loan Origination & Collateral Chain (LOC), and KYC/AML Evidence Ledger (KAL), plus a system evidence domain (SYS) covering RBIP's own access, key, disclosure, and continuity events. This revision corrects defects in draft-reilly-banking-integrity-01 that would have prevented independent verification. It replaces the -01 Merkle construction with the construction of [RFC9162] and prohibits leaf duplication; moves Merkle leaves from the payload digest to a digest over the full signed Evidence Item; resolves three conflicting definitions of prev_digest; separates the anchored Bundle Core from the mutable anchor and archival metadata, eliminating the -01 circularity in which the anchored digest could not match the archived artifact; replaces unsalted identifier hashes with salted field commitments; and resolves the -01 conflict between its plaintext officer-name fields and its own prohibition on plaintext personal data. This revision also adds an Evidence Coverage Attestation, because integrity of submitted evidence is not evidence of completeness; mandatory heartbeat bundles, so that truncation of an evidence chain is detectable; explicit pending and attested anchor states in place of a fixed confirmation count; a Suspicious Activity Report confidentiality section, because publicly archiving KAL bundle metadata as described in -01 could disclose the existence of a report; algorithm suite identifiers and bridging records for hash and signature migration; a key discovery and revocation mechanism; and a prohibition on automated remediation of integrity violations. RBIP is intended to help financial institutions evidence compliance with Basel III/IV, SOX, BSA/AML, DORA, MiCA, ISO/IEC 42001:2023, and other applicable regimes while preserving privacy, accountability, and auditability. This document is published as a prior art record in the sense described in [I-D.reilly-rem-protocol]: a public, timestamped disclosure under 35 U.S.C. 102(a)(1) [USC-35-102]. Publication as a prior art record is a record of disclosure and its date. It is not a determination of novelty, priority, or patentability, and no such determination is claimed here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Motivation 1.2. Scope 1.3. What RBIP Proves and Does Not Prove 1.4. Permanence and Prior Art Record Declaration 1.5. Changes from -01 2. Requirements Language 3. Terminology 4. Design Overview 4.1. Architecture and Modules 4.2. Threat Model 4.3. Trust Hierarchy 4.4. Conformance Classes 5. Data Model and Canonical Serialization 5.1. Common Cryptographic Constructions 5.1.1. Canonical Form 5.1.2. Digest Encoding and Algorithm Suites 5.1.3. Length-Prefixed Encoding 5.1.4. Merkle Tree Hash 5.1.5. Salted Field Commitments 5.1.6. Detached Signatures 5.2. Evidence Item Structure 5.3. Payload Modes 5.4. Evidence Bundle 5.4.1. Bundle Core 5.4.2. Bundle Manifest 5.4.3. Bundle Artifact 5.4.4. Heartbeat Bundles 5.5. Bundle Log and Proofs 5.6. Monetary Values 5.7. PRL Module Events 5.8. LOC Module Events 5.9. KAL Module Events 5.10. SYS Module Events 6. Protocol Workflow 6.1. Evidence Generation 6.2. Bundle Formation 6.3. Archival Deposit Step 6.4. Anchoring and Timestamping 6.5. Anchor States and Finality Policy 6.6. Permanence Attestation Record 6.7. Evidence Verification and Audit 6.8. Integrity Violation Handling 7. Interfaces and APIs 7.1. Internal Bank Systems Interface 7.2. Regulator / Auditor API 7.3. Public Transparency API 7.4. Webhook and Notification Interface 7.5. Key Discovery and Revocation 8. Cryptographic Requirements 8.1. Digest Algorithms 8.2. Signing and Key Management 8.3. HSM Requirements 8.4. Algorithm Migration and Bridging Records 9. Security Considerations 10. Privacy and Confidentiality Considerations 11. Compliance with Regulatory Standards 12. Implementation Guidance 13. IANA Considerations 14. Acknowledgments 15. References 15.1. Normative References 15.2. Informative References Appendix A. Detailed Changes from -01 Appendix B. Conformance Checklist Appendix C. Migration from rbip-01 Evidence Author's Address ------------------------------------------------------------------------ 1. Introduction 1.1. Motivation Financial regulators and auditors require trustworthy, tamper- evident records of banking operations. Conventional centralized logs and database snapshots are susceptible to undetectable alteration, retrospective deletion, or insider manipulation. Failures ranging from misstated reserve attestations to undocumented collateral substitution show that cryptographic evidence of what a record said, and when it said it, is a practical prerequisite for supervisory confidence. Existing audit practice relies on periodic sampling, self-reported attestations, and trusted-third-party certification. These mechanisms are effective at detecting many classes of error, but they do not produce records that an auditor can verify independently, continuously, and without the cooperation of the institution being examined. RBIP addresses that specific gap by combining two orthogonal mechanisms: o Archival deposit of evidence artifacts under a persistent, globally resolvable identifier, so that the artifact remains retrievable independently of any single institution. o Cryptographic anchoring of artifact digests to a public timestamping system, establishing a chronologically ordered, tamper-evident commitment that cannot be rewritten without detectable inconsistency. Together these mechanisms produce records that are durable, tamper-evident, and independently verifiable. Section 1.3 states precisely what that does and does not establish. 1.2. Scope RBIP is a protocol specification for the generation, deposit, anchoring, and verification of banking integrity evidence. It does NOT prescribe any particular timestamping platform, archival provider, or financial core system. Implementations MUST conform to the cryptographic requirements and data models specified herein but MAY choose conforming backends. RBIP covers: o Proof-of-Reserves and Liquidity attestations (PRL module) o Loan origination, underwriting, and collateral chain events (LOC module) o KYC/AML identity verification and case management (KAL module) o RBIP's own access, disclosure, key, coverage, and continuity events (SYS module) o Bundle formation, archival deposit, and anchoring workflows o Regulator, auditor, and public transparency interfaces o Security, privacy, and regulatory evidencing requirements RBIP does NOT cover: o Core banking transaction processing o Payment clearing and settlement protocols o Smart contract execution logic o Consensus mechanisms of any anchoring system o Determination of whether the evidenced conduct is compliant 1.3. What RBIP Proves and Does Not Prove This section is normative for how conforming implementations, auditors, and institutions MAY characterize RBIP output. It is new in -02 and exists because -01 could be read as claiming more than the construction supports. A verified RBIP evidence trail establishes: P1 Integrity: an Evidence Item that verifies against its bundle's merkle_root has not been altered since the bundle was formed. P2 Chronological upper bound: an anchored Bundle Core existed at or before the anchor's observed time, to the confidence provided by the anchoring system's finality properties. P3 Ordering: items within a module chain, and bundles within an institution chain, occupy the positions their hash links assert; insertion, deletion, or reordering after the fact is detectable. P4 Attribution to a key: an Evidence Item was signed by a key whose certificate or JWK the institution published, subject to the key state at signing time (Section 7.5). P5 Non-suppression within a cadence: absence of an expected heartbeat bundle (Section 5.4.4) is detectable, so silent truncation of the chain is detectable. A verified RBIP evidence trail does NOT establish: N1 Completeness: RBIP proves properties of the events that were submitted to it. It does not, by construction, prove that every event that occurred was submitted. An institution that never emits an event produces no evidence of that omission. This gap is addressed, but not closed, by the Evidence Coverage Attestation (Section 5.10.6); a Coverage Attestation is a signed claim about scope, and its truthfulness is a matter for examination, not for cryptography. N2 Correctness: RBIP does not establish that a reported reserve figure, valuation, or risk score is accurate. It establishes that a specific figure was recorded at a specific time and has not been changed since. N3 Regulatory compliance: RBIP produces evidence that supervisors and auditors may use. It does not determine compliance, and conformance to this document is not a compliance finding. N4 Priority or novelty of anything the evidence describes: see Section 1.4. N5 Absolute immutability: anchoring provides a commitment whose reversal is detectable and, for suitable systems, economically impractical. It is not a physical impossibility proof. Implementations, marketing materials, and API responses MUST NOT describe RBIP output in terms that assert N1 through N5. In particular, an implementation MUST NOT report a bundle as "complete", "compliant", or "final" where it means only that the bundle verified. 1.4. Permanence and Prior Art Record Declaration The RBIP specification is itself deposited and timestamped under the author's Reilly EternaMark (REM) Protocol [I-D.reilly-rem-protocol], applying Dual-Layer Digital Permanence with the addition of standards-body publication: Layer 1 -- Archival Deposit Under a Persistent Identifier: The foundational RBIP whitepaper was deposited and assigned a DOI on 13 September 2025, resolvable via the Handle System and indexed by DataCite: DOI: 10.5281/zenodo.17114424 URL: https://zenodo.org/records/17114424 Zenodo, operated by CERN, was the archival provider used for this specification. Conforming RBIP implementations MAY use any DataCite-member registration agency or equivalent persistent identifier infrastructure. The requirement is a globally resolvable, persistent identifier, not any specific platform. Layer 2 -- Public Timestamping: The specification artifact was submitted to a public timestamping service, producing a proof-of-existence attestation bound to a block whose timestamp is not alterable without producing a detectably inconsistent chain. OpenTimestamps anchored to the Bitcoin blockchain was used for this specification. Conforming implementations MAY use any public anchoring system that satisfies Section 6.4 and Section 6.5, including a Time-Stamp Protocol service per [RFC3161]. Layer 3 -- IETF Internet-Draft Publication: The protocol was submitted to the IETF as an Internet-Draft on 27 September 2025 (draft-reilly-banking-integrity-00), revised as -01 on 21 March 2026, and revised as this -02, recorded at: https://datatracker.ietf.org/doc/draft-reilly-banking-integrity/ IETF submission timestamps are publicly logged and independently retrievable from the IETF archive and its mirrors. Three independent records of the same disclosure make the fact and the date of that disclosure verifiable from three separately operated systems. Per [I-D.reilly-rem-protocol], Section 12.1, this constitutes a prior art record: a defensive publication whose content and date are independently checkable under 35 U.S.C. 102(a)(1) [USC-35-102]. Statements about what such a record establishes are deliberately narrow in this revision. A prior art record evidences that specified content was publicly available at a specified time. It does not establish novelty, inventorship, priority over any other work, or that no earlier equivalent disclosure exists, and this document makes no such claim. Text in -01 asserting that the timestamp precedes any subsequent derivative work or regulatory mandate, and that no existing product achieves these properties simultaneously, is withdrawn as unsupportable. 1.5. Changes from -01 Appendix A lists every change with its rationale. The changes fall into six groups: 1. Cryptographic corrections that were required for independent verification to be possible at all (Merkle construction, leaf input, prev_digest definition, signature construction, anchor input, and the separation of anchored content from mutable metadata). 2. Privacy corrections (salted commitments in place of unsalted identifier hashes, resolution of the plaintext-name conflict, SAR confidentiality, and minimization of publicly deposited metadata). 3. Assurance additions (Evidence Coverage Attestation, heartbeat bundles, SYS module, anchor states). 4. Agility additions (algorithm suite identifiers, bridging records, FIPS 140-3, post-quantum readiness). 5. Scale additions (Bundle Log, inclusion and consistency proofs, bulk range verification). 6. Editorial corrections (reference errors, incomplete IANA templates, dangling cross-references, and narrowed claims). Evidence produced under rbip-01 remains verifiable under -01 rules. Implementations MUST NOT re-hash or re-sign historical evidence to conform to this revision; see Appendix C. ------------------------------------------------------------------------ 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ------------------------------------------------------------------------ 3. Terminology Evidence Item: The atomic unit of RBIP. A structured, signed record capturing a discrete banking or system event, cryptographically linked to the preceding item in its module chain. item_digest: The digest, under the bundle's algorithm suite, of the canonical serialization of an Evidence Item with the "signature" member omitted. This is the value used for prev_digest linkage and as the Merkle leaf input. New in -02; see Section 5.2. Evidence Bundle: A set of Evidence Items aggregated over a defined interval. A bundle consists of a Bundle Core, a Bundle Manifest, and a Bundle Artifact (Section 5.4). Bundle Core: The immutable content of a bundle: identifiers, interval, item count, Merkle root, manifest digest, and chain linkage. The Bundle Core excludes all archival and anchoring metadata. Its digest, core_digest, is the only value that is chained and anchored. New in -02. core_digest: The digest of the canonical serialization of the Bundle Core. Once computed, core_digest never changes for that bundle. Bundle Manifest: The ordered list of Evidence Item references and item_digest values in a bundle. Committed to by manifest_digest in the Bundle Core. Bundle Artifact: What is deposited with the archival provider: the Bundle Core, the Permanence Attestation Record, and, where lawful, the Bundle Manifest in cleartext or encrypted form. Heartbeat Bundle: A bundle with item_count of zero, formed to prove that the evidence chain was live during an interval in which no events occurred. New in -02; see Section 5.4.4. Bundle Log: An append-only Merkle log, per [RFC9162], whose leaves are the core_digest values of an institution's bundles in order. Supports inclusion and consistency proofs over ranges. New in -02. Anchor: A commitment, recorded in a public timestamping system, to the anchor_input derived from a core_digest (Section 6.4). Anchor State: One of "pending", "attested", or "failed" (Section 6.5). New in -02, replacing the -01 fixed confirmation count. Field Commitment: A salted, keyed commitment to a single field value, permitting later selective disclosure without publishing the value. New in -02; see Section 5.1.5. Permanence Attestation Record (PAR): The record binding a core_digest to its archival identifier and its anchor or anchors, with their states. In -01 this structure was named the Triple-Layer Permanence Attestation (TLPA); the -02 structure is renamed because it now carries per-layer state and MAY reference more or fewer than three layers. Evidence Coverage Attestation: A signed SYS Evidence Item in which the institution states which source systems and event classes are in RBIP scope for a period, and asserts that in-scope events were submitted. New in -02; see Section 5.10.6 and Section 1.3, N1. Algorithm Suite: A named set of digest and signature algorithms, identified by alg_suite, under which a bundle and its items are computed (Section 5.1.2). New in -02. Bridging Record: A SYS Evidence Item binding evidence computed under one algorithm suite to a successor suite, so that pre-migration evidence remains verifiable after migration (Section 8.4). New in -02. PRL (Proof-of-Reserves & Liquidity): The module capturing reserve attestations, liquidity stress test outcomes, and regulatory capital snapshots. LOC (Loan Origination & Collateral Chain): The module capturing loan lifecycle events from application through default resolution. KAL (KYC/AML Evidence Ledger): The module capturing identity verification, transaction monitoring alerts, report filings, and case lifecycle events. SYS (System Evidence): The module capturing RBIP's own operation: auditor access, selective disclosure, key lifecycle, coverage attestation, continuity, and bridging events. New in -02. RBIP Node: A software component deployed within an institution that implements the Evidence Generation, Bundling, Deposit, and Anchoring workflows specified in this document. Auditor Interface: The API exposed to authorized regulators and auditors for evidence retrieval, proof verification, and anchor validation. HSM (Hardware Security Module): A tamper-resistant device used to generate, store, and use cryptographic keys. RBIP requires HSM-backed key operations for all Evidence Item and bundle signing. ------------------------------------------------------------------------ 4. Design Overview 4.1. Architecture and Modules RBIP comprises three compliance modules, one system evidence module, and a shared permanence layer: +-------------------------------------------------------------------+ | BANK CORE SYSTEMS | | (CBS, LOS, KYC Engine, AML Engine, Treasury Management System) | +-----------------------------------+-------------------------------+ | v +-------------------------------------------------------------------+ | RBIP EVIDENCE GENERATOR | | +------------+ +------------+ +------------+ +------------------+ | | | PRL Module | | LOC Module | | KAL Module | | SYS Module | | | | (Reserves) | | (Loans) | | (KYC/AML) | | (RBIP's own ops) | | | +-----+------+ +-----+------+ +-----+------+ +--------+---------+ | | | | | | | | +--------------+------+-------+-----------------+ | | | | | +----------v-----------+ | | | Bundle Aggregator | | | | (Core / Manifest) | | | +----------+-----------+ | | | | | +----------v-----------+ | | | Bundle Log | | | | (RFC 9162 Merkle log)| | | +----------+-----------+ | +---------------------------- | ------------------------------------+ | core_digest (immutable) +----------------+-----------------+ | | v v +-----------------------------+ +------------------------------+ | Archival Deposit Service | | Anchoring Service | | (persistent identifier) | | (public timestamping) | +--------------+--------------+ +--------------+---------------+ | | +--------------+-----------------+ | +--------------v---------------+ | Permanence Attestation Record| | (per-layer state) | +--------------+---------------+ | +-------------+----------+-----------+------------------+ | | | | v v v v +---------+ +-------------+ +---------------------+ +-----------+ |Regulator| | Public | | Internal Compliance | | Key and | |/Auditor | |Transparency | | Dashboard | |Revocation | | API | | API | | | | Discovery | +---------+ +-------------+ +---------------------+ +-----------+ The RBIP Node integrates with core systems via an event adapter layer. Events flow through the Evidence Generator, are aggregated into Bundle Cores and Manifests, appended to the Bundle Log, and then deposited and anchored. Critically, and unlike -01, deposit and anchoring never modify the Bundle Core; they populate the Permanence Attestation Record, which is versioned separately. 4.2. Threat Model RBIP is designed to resist the following adversaries. T1 through T7 are carried forward from -01 with corrected countermeasures; T8 through T11 are new in -02. T1 -- Retrospective Record Modification: An actor with database access alters historical records. Countered by item_digest chaining, Merkle commitment over full signed items, and anchoring of core_digest. Note that -01's countermeasure was incomplete: because -01 built its Merkle tree over data_digest, which covered only the payload, modifications to an item's envelope (timestamp, prev_digest, module, evidence_id) did not change the -01 merkle_root. Section 5.4.1 corrects this. T2 -- Record Deletion and Chain Truncation: An actor deletes records, or stops emitting evidence for a period and later resumes. Countered by chain linkage, by archival deposit, and, new in -02, by mandatory heartbeat bundles: an auditor detects an interval with no bundle at all, which -01 could not distinguish from an interval with no events. T3 -- Event Reordering: Countered by prev_digest chaining over item_digest, by Merkle position, and by the Bundle Log's ordering. T4 -- Insider Collusion with the Archival Operator: Operators collude to replace a deposited artifact. Countered by anchoring: the anchored anchor_input is derived from core_digest alone, so a replacement artifact yields a different core_digest. In -01 this countermeasure was defeated by the workflow itself: Section 6.4, Step 5 of -01 recomputed bundle_digest after anchoring, so the anchored digest was guaranteed not to match the final deposited artifact. Section 5.4 and Section 6.4 correct this. T5 -- Customer Data Exposure: An attacker or an over-broad auditor request exposes personal or confidential data. Countered by commitment-mode payloads (Section 5.3), salted field commitments (Section 5.1.5), certificate-bound access control, evidenced selective disclosure (Section 5.10.2), and minimization of publicly deposited metadata (Section 10.5). -01 referred to zero-knowledge proofs "per Section 7.3", but -01 Section 7.3 specified no such mechanism; that dangling reference is removed and replaced by the commitment and selective disclosure mechanisms actually defined here. T6 -- Timestamp Fraud: An actor backdates an event. Countered by anchoring, which bounds the time of existence from above. RBIP does not bound it from below: an actor can always anchor an event later than it occurred, or fabricate an event and anchor it promptly. Anchor latency monitoring (Section 6.5) makes systematic late anchoring visible. T7 -- API Replay: Countered by idempotency keys, nonces, and mutually authenticated TLS. T8 -- Selective Non-Submission (new): An actor simply does not submit inconvenient events, producing a trail that is internally perfect and materially incomplete. RBIP cannot cryptographically prevent this; see Section 1.3, N1. It is addressed by Evidence Coverage Attestations, by requiring source-system sequence references in coverage claims, and by making the attestation itself a signed, anchored, non-repudiable statement whose falsity is attributable to a named officer. T9 -- Cross-Bundle Equivocation (new): An institution maintains two divergent evidence histories and shows different ones to different verifiers. Countered by the Bundle Log with consistency proofs (Section 5.5): a verifier can require a consistency proof between any two log states it has seen, and divergence is detectable. T10 -- Commitment Brute Force (new): An adversary who obtains a commitment to a low-entropy value, such as a national identifier, account number, or date of birth, recovers the value by exhaustive search. -01 was vulnerable to this by design: it specified unsalted SHA-256 over stable internal identifiers and treated the result as privacy protection. Countered in -02 by per-field random salts of at least 32 octets held under HSM control (Section 5.1.5). T11 -- Report Existence Disclosure (new): A third party infers, from publicly deposited bundle metadata, that a suspicious activity report was filed about a subject or in a period. -01 deposited a manifest listing every evidence_id with its module prefix, and defined a public interface returning per-module bundle counts, which together could reveal the existence of a report. Countered by Section 10.4 and Section 10.5. 4.3. Trust Hierarchy Level 1 -- RBIP Node (institution-controlled): Generates and signs Evidence Items. Trusted for capture and serialization only. MUST perform all signing in an HSM (Section 8.3). A verifier MUST NOT treat Level 1 output as trustworthy in respect of completeness (Section 1.3, N1). Level 2 -- Archival Deposit Provider: Preserves Bundle Artifacts under a persistent identifier. Trusted for retrievability, not for integrity: integrity comes from core_digest, which the verifier recomputes. Level 3 -- Anchoring Service: Commits anchor_input to a public system. Trusted for chronological ordering to the extent of its finality properties, which MUST be stated in the finality policy (Section 6.5). Level 4 -- Independent Auditors and Regulators: Verify cryptographically and trust nothing else. A conforming deployment MUST permit a Level 4 verifier to complete every step of Section 6.7 using only the deposited artifact, the public anchoring system, and the published key material, with no institutional cooperation beyond serving the manifest and proofs it is entitled to receive. 4.4. Conformance Classes -01 defined no conformance classes, which made "RBIP compliant" unfalsifiable. This revision defines three. RBIP-Core: Implements Sections 5.1 through 5.5, Section 6, Section 7.1, Section 7.5, Section 8, and the SYS module event types marked REQUIRED in Section 5.10. At least one compliance module MUST be implemented. RBIP-Core is the minimum that MAY be described as conforming to this document. RBIP-Audited: RBIP-Core plus Section 7.2 (Regulator / Auditor API) including inclusion proofs, consistency proofs, and evidenced selective disclosure. RBIP-Transparent: RBIP-Audited plus Section 7.3 (Public Transparency API), subject to Section 10.5. An implementation MUST state its class and its implemented modules in the response to GET /.well-known/rbip (Section 7.5). An implementation MUST NOT claim a class whose REQUIRED elements it does not implement. Appendix B provides a mechanical checklist; a claim of conformance SHOULD be accompanied by the completed checklist. ------------------------------------------------------------------------ 5. Data Model and Canonical Serialization 5.1. Common Cryptographic Constructions This section is new in -02. In -01, cryptographic constructions were stated informally at their points of use, which produced the inconsistencies catalogued in Appendix A. All constructions are now defined once, here, and referenced elsewhere. 5.1.1. Canonical Form JSON structures defined in this document MUST be serialized using the JSON Canonicalization Scheme [RFC8785] before hashing or signing. Canonical form MUST NOT contain insignificant whitespace. Implementations MUST NOT use general-purpose JSON serializers or pretty-printers for these operations. Implementations that use CBOR MUST use the deterministic encoding requirements of [RFC8949], Section 4.2.1. Where a structure is produced in both encodings, the JSON canonical form is normative for digest computation unless the algorithm suite specifies otherwise. Where this document says a member is "omitted", the member MUST be absent from the canonical form. -01 in places directed that a member be set to the empty string instead; the two are not equivalent under [RFC8785] and produce different digests. Where -02 says omitted, an empty string MUST NOT be substituted. 5.1.2. Digest Encoding and Algorithm Suites A digest value appearing in an RBIP structure MUST be encoded as the algorithm label, a colon, and the lowercase hexadecimal digest, for example: sha256:3f79bb7b435b05321651daefd374cd21b4d3f0ac1a3d0b1b9a4f2e1c... Defined labels are "sha256", "sha384", "sha3-256", and "sha3-512". Every Evidence Item and every Bundle Core MUST carry an alg_suite member naming the algorithm suite under which all of its digests and signatures are computed. Mixing suites within a bundle is PROHIBITED. Suites defined by this document: +------------------+-----------+-----------------+-----------------+ | alg_suite | Digest | Signature | Status | +------------------+-----------+-----------------+-----------------+ | rbip-suite-1 | SHA-256 | ES256 | REQUIRED | | rbip-suite-2 | SHA-256 | Ed25519 | RECOMMENDED | | rbip-suite-3 | SHA-384 | ES384 | RECOMMENDED for | | | | | PRL | | rbip-suite-4 | SHA3-256 | ES256 | OPTIONAL | | rbip-suite-5 | SHA-256 | RS256 (>=3072) | OPTIONAL, | | | | | legacy only | | rbip-suite-pq-1 | SHA-384 | ML-DSA-65 | OPTIONAL | | | | [FIPS-204] | | | rbip-suite-pq-2 | SHA-384 | ES384 + | OPTIONAL, | | | | ML-DSA-65 | composite | +------------------+-----------+-----------------+-----------------+ Every conforming implementation MUST support rbip-suite-1. MD5 and SHA-1 MUST NOT be used for any purpose in RBIP. Section 8.4 specifies how an institution moves between suites without invalidating existing evidence. Section 13.4 requests an IANA registry so that further suites can be defined without revising this document; -01 provided no such extension point. 5.1.3. Length-Prefixed Encoding Several constructions in -01 concatenated values without length delimitation, most importantly the -01 anchor payload sha256(bundle_digest || doi_uri_bytes). Unprefixed concatenation of variable-length values is ambiguous: distinct input pairs can produce identical byte strings. All concatenation in -02 uses the length-prefixed encoding LP: LP(x) = uint32_be(length_in_octets(x)) || x where uint32_be is a four-octet big-endian unsigned integer. A value whose length exceeds 2^32 - 1 octets MUST be rejected. 5.1.4. Merkle Tree Hash RBIP uses the Merkle Tree Hash of [RFC9162], Section 2.1.1, with HASH being the digest function of the applicable algorithm suite. Given an ordered list D[n] = {d(0), ..., d(n-1)} of digest values in raw octet form: MTH({}) = HASH() MTH({d(0)}) = HASH(0x00 || d(0)) For n > 1, with k the largest power of two strictly less than n: MTH(D[n]) = HASH(0x01 || MTH(D[0:k]) || MTH(D[k:n])) The 0x00 and 0x01 prefixes are domain separators between leaf and internal nodes and MUST be included. Implementations MUST NOT duplicate the final leaf to balance an odd-sized tree. -01 required exactly that, and attributed the requirement to [RFC9162], Section 2.1, which specifies no such thing. Leaf duplication permits distinct leaf sequences to produce an identical root, so a verifier cannot determine which sequence a root commits to. Any bundle whose root was computed with leaf duplication MUST be treated as non-conforming under -02. Inclusion proofs and consistency proofs MUST be computed and verified as specified in [RFC9162], Sections 2.1.3 and 2.1.4. 5.1.5. Salted Field Commitments A field commitment permits an institution to commit to a field value without publishing it, and to disclose it later in a manner a verifier can check against the commitment. For a field with JSON Pointer path [RFC6901] p and canonical value v, the commitment is: salt = 32 or more octets from a CSPRNG, unique per field per item c = HMAC-HASH(salt, LP("RBIP-FC-v2") || LP(p) || LP(v)) where HMAC-HASH is HMAC [RFC2104] with the digest of the algorithm suite. Salts MUST be generated inside, or under the control of, the HSM boundary and MUST be stored under the same protection as subject encryption keys (Section 10.3). Salts MUST NOT be included in any Evidence Item, Bundle Core, Bundle Manifest, Bundle Artifact, or public interface response. The set of commitments for an item is aggregated as: fields_root = MTH(sorted set of c values, ascending by p) Ordering MUST be by the canonical byte sequence of p, so that fields_root is reproducible. Disclosure of a field is the tuple (p, v, salt), which a verifier recomputes to c and checks for inclusion under fields_root using an inclusion proof per Section 5.1.4. Unsalted digests of identifiers MUST NOT be used as a privacy mechanism. -01 specified unsalted SHA-256 over stable internal applicant, customer, underwriter, and destination account identifiers, and described the result as compliant with its own privacy requirements. Identifiers of this kind have low entropy and are recoverable by exhaustive search, so an unsalted digest provides no meaningful confidentiality against an adversary who knows the identifier format. All such fields are commitment-mode fields in -02; see Section 5.3 and Appendix A. 5.1.6. Detached Signatures -01 specified that the "signature" member contain a JWS Compact Serialization over the canonical Evidence Item, and separately that it be computed with the signature member set to the empty string and also that it exclude the signature member. These are three different constructions, and the first is circular in practice because a JWS Compact Serialization carries its own payload copy. In -02, RBIP signatures are detached-payload signatures: o The signing input is the canonical serialization of the structure with the "signature" member (or "bundle_signature", "par_signature") omitted. o A conforming signature MUST be a JWS using unencoded, detached payload per [RFC7515] and [RFC7797], with the protected header containing "alg" matching the algorithm suite, "b64" set to false, "crit" containing "b64", and "kid" identifying the signing key as published under Section 7.5. The value carried in the RBIP member is the JWS with an empty payload segment (header..signature). o An implementation MAY additionally carry a COSE_Sign1 [RFC9052] [RFC9053] signature with a detached payload in the OPTIONAL "signature_cose" member. Where both are present, both MUST verify. The signing input for an Evidence Item is defined in Section 5.2; for a Bundle Core in Section 5.4.1; for a Permanence Attestation Record in Section 6.6. 5.2. Evidence Item Structure An Evidence Item MUST be serialized in canonical form per Section 5.1.1. Evidence Item JSON Schema (informative summary of normative requirements; the schema is published as https://remweb4.org/schema/rbip/evidence-item-2 and implementations MUST NOT depend on network resolution of that URI): { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://remweb4.org/schema/rbip/evidence-item-2", "type": "object", "required": [ "evidence_id", "schema_version", "alg_suite", "module", "event_type", "institution_id", "timestamp", "prev_digest", "payload_mode", "signature" ], "properties": { "evidence_id": { "type": "string", "pattern": "^(PRL|LOC|KAL|SYS)-[0-9a-f]{8}-[0-9a-f]{4}-[47][0-9a-f]{3} -[89ab][0-9a-f]{3}-[0-9a-f]{12}$", "description": "Module-prefixed UUID v4 or v7 [RFC9562]." }, "schema_version": { "type": "string", "const": "rbip-02" }, "alg_suite": { "type": "string", "description": "Algorithm suite label per Section 5.1.2." }, "module": { "type": "string", "enum": ["PRL", "LOC", "KAL", "SYS"] }, "event_type": { "type": "string", "description": "An event type registered per Section 13.5." }, "institution_id": { "type": "string", "description": "LEI [ISO17442] or BIC [ISO9362] of the reporting institution." }, "timestamp": { "type": "string", "format": "date-time", "description": "Occurrence time, [RFC3339], UTC offset Z." }, "recorded_at": { "type": "string", "format": "date-time", "description": "Time the RBIP Node created this item. MUST be present where it differs from timestamp by more than the configured capture SLA." }, "prev_digest": { "type": "string", "description": "item_digest of the immediately preceding Evidence Item in the same module chain for this institution_id, or the all-zero digest for the genesis item." }, "payload_mode": { "type": "string", "enum": ["inline", "commitment", "mixed"], "description": "See Section 5.3." }, "data_fields": { "type": "object", "description": "Cleartext payload. Present only for fields in inline mode." }, "data_digest": { "type": "string", "description": "Digest of the canonical serialization of data_fields. REQUIRED when data_fields is present." }, "field_commitments": { "type": "array", "description": "Commitment-mode fields. Each entry is {path, commitment}, where path is a JSON Pointer and commitment is a digest string.", "items": { "type": "object", "required": ["path", "commitment"], "properties": { "path": { "type": "string" }, "commitment": { "type": "string" } } } }, "fields_root": { "type": "string", "description": "Merkle root over field_commitments per Section 5.1.5. REQUIRED when field_commitments is present." }, "metadata": { "type": "object", "properties": { "regulatory_ref": { "type": "string" }, "jurisdiction": { "type": "string" }, "tags": { "type": "array", "items": { "type": "string" } }, "rbip_node_id": { "type": "string" }, "operator_ref": { "type": "string" }, "source_system": { "type": "string" }, "source_seq": { "type": "string" } }, "description": "operator_ref MUST be a commitment, not a name or employee identifier. source_system and source_seq support coverage verification per Section 5.10.6." }, "signature": { "type": "string", "description": "Detached JWS per Section 5.1.6 over the canonical item with signature omitted." }, "signature_cose": { "type": "string", "description": "OPTIONAL detached COSE_Sign1, base64url." } } } The following are normative: o item_digest is the digest, under alg_suite, of the canonical serialization of the Evidence Item with the "signature" and "signature_cose" members omitted. item_digest is not carried inside the item; it is computed by producers and verifiers alike and appears in the Bundle Manifest and in the successor item's prev_digest. o prev_digest MUST equal the item_digest of the immediately preceding Evidence Item in the same module chain for the same institution_id. For the genesis item of a module chain, prev_digest MUST be the algorithm label followed by a colon and the appropriate number of zero hex digits, for example "sha256:" followed by 64 zeros. -01 defined prev_digest three inconsistent ways: as the digest of the preceding item (Section 3), as the preceding item's data_digest (Section 6.1, Step 3), and as the digest of the preceding item's canonical serialization (Section 6.6, Step 5). Chains built to any two of these definitions do not interoperate. This definition supersedes all three. o data_digest, when present, MUST be computed over the canonical serialization of data_fields only. It exists for payload integrity checking during inline disclosure and MUST NOT be used as a Merkle leaf, as a chain link, or as an anchor input. o At least one of data_fields or field_commitments MUST be present, consistent with payload_mode. o timestamp MUST use a UTC offset of "Z". Where an institution's source system records local time, conversion MUST occur before item construction and the source offset SHOULD be recorded as a commitment-mode field. 5.3. Payload Modes Every Evidence Item declares a payload_mode: inline: All payload fields appear in cleartext in data_fields, and data_digest is present. Permitted only where no field carries personal data, confidential supervisory information, or information subject to Section 10.4. commitment: No cleartext payload is carried. field_commitments and fields_root are present. Cleartext values and salts remain under institutional control and are released only through evidenced selective disclosure (Section 5.10.2 and Section 7.2.5). mixed: Non-sensitive fields appear in data_fields with data_digest; sensitive fields appear as commitments with fields_root. A field MUST NOT appear in both. The following are normative: o All KAL module items MUST use commitment or mixed mode. KAL items MUST NOT be emitted in inline mode. o Any field identifying a natural person, directly or indirectly, MUST be a commitment-mode field. This includes, without limitation, the -01 fields attestation_officer, attestor_name, applicant_hash, underwriter_hash, customer_hash, destination_hash, doc_hash, sar_reference_hash, and escalation_reason. o -01 required in Section 10.1 that personal data never appear in plaintext, and required in Sections 5.4.1 and 5.4.3 that attestation_officer and attestor_name carry a name and role in plaintext. A conforming -01 implementation could not satisfy both. -02 resolves the conflict in favour of Section 10.1: names are commitments; role, institution LEI, and scope may be inline. o Structural members (evidence_id, module, event_type, institution_id, timestamp, prev_digest, alg_suite, payload_mode) are never commitment-mode. They are always cleartext, because verification of ordering and inclusion depends on them. 5.4. Evidence Bundle A bundle has three parts. Separating them is the principal structural change in -02, and it exists to fix a defect that made -01 unverifiable: -01 placed the DOI and the blockchain anchor inside the same object whose digest was anchored, then in Section 6.4, Step 5 recomputed that digest after anchoring and re-deposited the object. The anchored digest therefore committed to a version of the bundle that no longer existed, and the deposited artifact's digest was not the anchored value. 5.4.1. Bundle Core The Bundle Core is immutable from the moment it is formed. It contains no archival or anchoring metadata. { "bundle_id": "", "schema_version": "rbip-02", "alg_suite": "", "institution_id": "", "bundle_type": "events" | "heartbeat", "modules_included": ["PRL", "LOC", "KAL", "SYS"], "interval_start": "", "interval_end": "", "item_count": , "merkle_root": "", "manifest_digest": "", "prev_core_digest": "", "bundle_seq": , "coverage_ref": "", "bundle_signature": "" } Normative requirements: o merkle_root MUST be MTH over the ordered list of item_digest values of the items in the bundle, computed per Section 5.1.4. -01 used data_digest values as leaves, which committed only to payloads; an item's timestamp, prev_digest, module, evidence_id, and signature were outside the -01 root. Two items with identical payloads also produced identical -01 leaves. o For a heartbeat bundle, merkle_root MUST be MTH({}), that is the digest of the empty octet string, and manifest_digest MUST be the digest of the canonical empty manifest. o prev_core_digest MUST be the core_digest of the immediately preceding bundle for this institution_id, across all modules, or the all-zero digest for the first bundle. The bundle chain is per institution, not per module; per-module ordering is carried by prev_digest within items. o bundle_seq MUST increase by exactly one per bundle for the institution. A gap in bundle_seq is an integrity violation (Section 6.8). o core_digest is the digest, under alg_suite, of the canonical serialization of the Bundle Core with "bundle_signature" omitted. core_digest MUST NOT be recomputed after formation for any reason, including anchoring, re-deposit, or algorithm migration. o bundle_signature is a detached JWS over that same canonical serialization. o Items are ordered ascending by timestamp, then by recorded_at where present, then lexicographically by evidence_id. The ordering rule MUST be applied identically by producers and verifiers. 5.4.2. Bundle Manifest { "bundle_id": "", "alg_suite": "", "entries": [ { "index": 0, "evidence_id": "", "item_digest": "", "module": "PRL" }, ... ] } manifest_digest in the Bundle Core is the digest of the canonical serialization of this object. The manifest permits a verifier to recompute merkle_root directly. Section 10.5 governs whether, and in what form, the manifest may be deposited publicly. 5.4.3. Bundle Artifact The Bundle Artifact is what is deposited with the archival provider: { "artifact_version": "rbip-02", "bundle_core": { ... as Section 5.4.1 ... }, "par": { ... as Section 6.6 ... }, "manifest": { ... } | null, "manifest_enc": "" | null, "manifest_enc_alg": "" | null } Exactly one of manifest, manifest_enc, or neither MUST be present. Where manifest_enc is present, decryption MUST yield the canonical manifest whose digest equals manifest_digest. Where neither is present, the institution MUST serve the manifest through the Auditor API (Section 7.2), and MUST record in the PAR that manifest availability depends on institutional cooperation, which weakens the T2 deletion countermeasure accordingly. Depositing an updated Bundle Artifact as a new version of the same persistent identifier is expected: the PAR changes as anchor state advances. Because bundle_core is byte-identical across those versions, core_digest is stable and every version is verifiable against the same anchor. 5.4.4. Heartbeat Bundles An institution MUST form a bundle at least once per heartbeat interval per active institution chain, whether or not any events occurred. The heartbeat interval MUST NOT exceed 24 hours and SHOULD NOT exceed 1 hour for institutions operating continuous monitoring. Where no events occurred, bundle_type MUST be "heartbeat". Heartbeat bundles are formed, chained, deposited, and anchored exactly as event bundles. A verifier that observes no bundle for an interval exceeding the institution's declared heartbeat interval MUST report CHAIN_STALE and MUST NOT treat the trail as verified through the present. -01 required at least one bundle per day per active module but provided no way to distinguish an interval with no events from an interval whose evidence was suppressed, so a truncated trail was indistinguishable from a quiet one. Heartbeats close that gap. 5.5. Bundle Log and Proofs An institution MUST maintain a Bundle Log: an append-only Merkle log per [RFC9162] whose leaves, in order, are the core_digest values of its bundles. The log's tree head at size n is log_root(n). The RBIP Node MUST be able to produce, on request: o An inclusion proof for an item_digest under a bundle's merkle_root. o An inclusion proof for a core_digest under log_root(n). o A consistency proof between log_root(m) and log_root(n) for m <= n, per [RFC9162], Section 2.1.4. Consistency proofs are what make equivocation (T9) detectable: a verifier that has previously recorded log_root(m) can require proof that the current log extends it rather than diverging from it. Verifiers SHOULD retain every log root they observe, with its anchor, for this purpose. For examinations spanning long ranges, an implementation MAY support bulk subtree consistency proofs as described in [I-D.reilly-plants-bulk-subtree-proofs], which verify a contiguous range of the log by descent over full subtrees at landmark breakpoints rather than by per-leaf proofs. Support is OPTIONAL; where offered, the response MUST also be verifiable by the [RFC9162] construction, so that a verifier without bulk support is never disadvantaged. Log roots MUST themselves be anchored at least once per heartbeat interval. Anchoring the log root, in addition to individual core_digest values, allows a single anchor to cover an arbitrary number of bundles and materially reduces anchoring cost for high-volume institutions. 5.6. Monetary Values -01 required monetary amounts to be strings of the form " ", which requires parsing to compare and admits locale variation inside the amount. In -02 a monetary value is an object: { "amount": "", "currency": "", "scale": } The amount MUST match the pattern ^-?[0-9]+(\.[0-9]+)?$ using ASCII digits only. Group separators, currency symbols, and exponent notation MUST NOT appear. Implementations MUST NOT convert monetary values to binary floating point at any point in evidence construction. Where scale is present it MUST equal the number of digits after the decimal point in amount. Fields carrying monetary values in Sections 5.7 through 5.9 use this object. Appendix C describes handling of -01 string-form values in historical evidence, which MUST NOT be rewritten. 5.7. PRL Module Events The PRL module captures reserve, liquidity, and capital adequacy events. Event types are as in -01 with the corrections noted. 5.7.1. ReserveSnapshot data_fields (inline unless otherwise noted): { "snapshot_type": "daily_close" | "regulator_requested" | "stress_triggered", "reporting_date": "", "reserve_assets": [ { "asset_class": "cash" | "hqla_l1" | "hqla_l2a" | "hqla_l2b" | "other", "asset_ref": "", "market_value": , "haircut_pct": "", "post_haircut_value": } ], "total_hqla": , "lcr_ratio": "", "nsfr_ratio": "", "tier1_capital_ratio": "", "attestation_officer_ref": "", "attestation_officer_role": "CFO" | "CRO" | "treasurer" | "controller" | "other", "attestation_method": "automated_system" | "manual_review" | "external_audit", "source_system": "" } attestation_officer in -01 carried a name and employee identifier in cleartext. In -02 the identity is a commitment; the role is inline, because supervisory value comes from knowing that a person holding that role attested, and the identity can be disclosed to an authorized examiner under Section 7.2.5. 5.7.2. LiquidityStressTest { "stress_scenario": "regulatory_standard" | "adverse" | "severely_adverse" | "institution_defined", "scenario_id": "", "horizon_days": , "baseline_lcr": "", "stressed_lcr": "", "survival_days": , "assumptions": [ { "parameter": "", "value": "", "basis": "" } ], "model_id": "", "model_version": "", "model_digest": "", "run_timestamp": "" } model_digest is new in -02. A model version string alone does not establish which artifact produced a result; a digest does, and it is what supports the ISO/IEC 42001 traceability claim in Section 11.6 that -01 made on the strength of a version string. 5.7.3. ReserveAttestation { "attests_to_item": "", "attests_to_digest": "", "attestor_ref": "", "attestor_role": "CFO" | "CRO" | "external_auditor" | "regulator", "attestor_institution": "", "attestation_scope": "", "attestation_sig": "", "attestor_key_ref": "" } -01 referenced attests_to_snapshot_id without binding the digest, so an attestation did not identify which version of a snapshot was attested; attests_to_digest closes that. -01 specified an armored PGP signature alongside an X.509 certificate reference without stating how a verifier resolves either; -02 requires a signature verifiable against key material discoverable per Section 7.5. 5.8. LOC Module Events 5.8.1. LoanApplication { "application_ref": "", "application_date": "", "loan_type": "residential_mortgage" | "commercial_real_estate" | "auto" | "personal" | "sme" | "syndicated" | "other", "requested_amount": , "requested_term_months": , "applicant_ref": "", "origination_channel": "branch" | "digital" | "broker" | "wholesale", "jurisdiction": "" } applicant_ref replaces the -01 applicant_hash. The -01 field was an unsalted SHA-256 over a stable internal applicant identifier and was described as satisfying the privacy requirements of -01 Section 10; it did not, for the reason given in Section 5.1.5. The same substitution applies to every -01 field of the form *_hash that committed to an identifier. 5.8.2. UnderwritingDecision { "application_ref": "", "decision": "approved" | "declined" | "referred" | "conditionally_approved", "decision_date": "", "decision_rationale": "", "approved_amount": , "approved_rate": "", "approved_term_months": , "conditions": [ { "condition_ref": "", "deadline": "" } ], "decision_model_id": "", "decision_model_version": "", "decision_model_digest": "", "adverse_action_ref": "", "underwriter_ref": "" } 5.8.3. CollateralBinding { "loan_ref": "", "collateral_ref": "", "collateral_type": "residential_property" | "commercial_property" | "securities" | "vehicle" | "equipment" | "cash_deposit" | "guarantee" | "other", "external_ref": "", "valuation": , "valuation_method": "automated_valuation" | "desktop_appraisal" | "full_appraisal" | "market_price", "valuation_date": "", "ltv_ratio": "", "lien_position": "first" | "second" | "subordinate", "binding_date": "", "perfection_ref": "" } 5.8.4. CollateralRevaluation { "collateral_ref": "", "prior_valuation": , "prior_valuation_item": "", "new_valuation": , "revaluation_date": "", "trigger": "scheduled_review" | "market_event" | "borrower_request" | "regulator_order" | "impairment_indicator", "revaluation_method": "automated_valuation" | "desktop_appraisal" | "full_appraisal" | "market_price", "updated_ltv_ratio": "", "margin_call_triggered": } prior_valuation_item is new in -02. Collateral substitution and silent revaluation are the abuses this module exists to detect, and detecting them requires each revaluation to name the exact prior record it supersedes. 5.8.5. LoanDisbursement { "loan_ref": "", "disbursement_ref": "", "disbursement_date": "", "amount": , "disbursement_method": "wire_transfer" | "ach" | "check" | "internal_credit", "destination_ref": "", "conditions_satisfied": [ { "condition_ref": "", "satisfied_date": "" } ] } 5.8.6. PaymentReceipt { "loan_ref": "", "payment_ref": "", "payment_date": "", "amount": , "principal_component": , "interest_component": , "fees_component": , "days_past_due": , "payment_channel": "ach" | "wire" | "internal" | "cash" | "check" } 5.8.7. DefaultEvent / RecoveryEvent { "loan_ref": "", "event_subtype": "default_declaration" | "recovery_partial" | "recovery_full" | "charge_off" | "workout_agreement", "event_date": "", "days_past_due_at_default": , "outstanding_balance": , "recovery_amount": , "lgd_estimate": "", "resolution_timeline_days": } 5.9. KAL Module Events All KAL items MUST use commitment or mixed payload mode (Section 5.3). Section 10.4 imposes additional constraints on KAL evidence where report confidentiality law applies. 5.9.1. IdentitySubmission { "submission_ref": "", "submission_date": "", "customer_type": "individual" | "entity" | "correspondent_bank" | "pep", "identity_doc_type": "passport" | "national_id" | "drivers_license" | "entity_registration" | "other", "doc_ref": "", "liveness_check_result": "pass" | "fail" | "not_required", "submission_channel": "branch" | "digital_onboarding" | "api_partner" } doc_ref commits to the identity document or its digest. An identity document image MUST NOT be carried in an Evidence Item in any mode, encrypted or otherwise. 5.9.2. IdentityVerificationResult { "submission_ref": "", "verification_date": "", "result": "verified" | "failed" | "referred" | "escalated", "verification_method": "automated_ocr_biometric" | "manual_review" | "third_party_bureau" | "video_interview", "risk_score": "", "risk_tier": "", "sanctions_checked": , "pep_checked": , "adverse_media_checked": , "next_review_date": "" } risk_score and risk_tier are commitment-mode in -02. In -01 they were inline alongside an unsalted customer hash, which let anyone with the deposited evidence link a recoverable identifier to a risk classification. 5.9.3. TransactionMonitorAlert { "alert_ref": "", "alert_generated_at": "", "alert_type": "", "rule_id": "", "rule_digest": "", "customer_ref": "", "transaction_count": "", "aggregate_amount": "", "risk_score": "", "auto_disposition": "" } 5.9.4. ReportSubmission Renamed from the -01 SARSubmission. The -01 name encoded the existence of a suspicious activity report in the event type itself, which appears in the Bundle Manifest and, under -01, in publicly deposited metadata. See Section 10.4. { "report_ref": "", "submission_date": "", "jurisdiction": "", "receiving_authority": "", "activity_type": "", "subject_count": "", "reporting_period_start": "", "reporting_period_end": "", "filing_status": "" } Every field of this event type is commitment-mode. The event type string "ReportSubmission" covers regulatory filings generally and does not by itself indicate that a suspicious activity report exists. 5.9.5. CaseEscalation { "case_ref": "", "escalation_date": "", "from_tier": "", "to_tier": "", "escalation_reason": "", "linked_alert_refs": "", "linked_report_refs": "" } 5.9.6. CaseClosure { "case_ref": "", "closure_date": "", "closure_outcome": "", "investigation_duration_days": "", "disposition_ref": "" } 5.10. SYS Module Events The SYS module is new in -02. -01 required that several classes of event be "RBIP-evidenced" without defining any event type capable of carrying them: the auditor access log (-01 Section 7.2), the Key Compromise Event (-01 Section 9.3), the HSM audit log (-01 Section 8.3), and selective disclosure requests, which -01 directed be recorded as a KAL CaseEscalation, a category error that would have placed regulator access records inside the AML case chain. SYS items are inline mode except where noted. Support for AccessRecord, DisclosureRecord, KeyLifecycleRecord, ContinuityRecord, and CoverageAttestation is REQUIRED for RBIP-Core. BridgingRecord is REQUIRED for any institution that changes algorithm suite. 5.10.1. AccessRecord { "interface": "auditor" | "internal" | "public", "endpoint": "", "method": "", "client_ref": "", "client_org": "", "authorization_ref": "", "request_digest": "", "response_status": , "records_returned": , "accessed_at": "" } Every request to the Auditor API MUST produce an AccessRecord. AccessRecords MUST be bundled and anchored like any other evidence, and MUST NOT be excluded from the manifest. 5.10.2. DisclosureRecord { "disclosure_ref": "", "requester_org": "", "authorization_ref": "", "legal_basis": { "authority": "", "instrument": "", "instrument_date": "" }, "scope": { "bundle_ids": ["", ...], "evidence_ids": ["", ...], "field_paths": ["", ...] }, "disclosed_at": "", "disclosure_digest": "" } A selective disclosure MUST NOT be performed until the corresponding DisclosureRecord has been created and committed. The record commits to what was released, to whom, and under what authority, and is itself evidence. legal_basis is structured rather than the -01 free-text "purpose" field, because an unstructured purpose string cannot be examined systematically. 5.10.3. KeyLifecycleRecord { "key_ref": "", "event": "generated" | "activated" | "rotated" | "deactivated" | "revoked" | "compromised", "alg_suite": "", "public_key_digest": "", "not_before": "", "not_after": "", "predecessor_key_ref": "", "reason": "", "effective_at": "", "signed_by_key_ref": "" } A revocation or compromise record MUST be signed by a successor key or by an offline institutional root key, never by the key it describes. A verifier evaluating a historical signature MUST use the key state as of the item's timestamp, taking revocation effective_at into account, so that revocation does not retroactively invalidate evidence signed while the key was valid, and does not validate evidence signed after compromise. 5.10.4. ContinuityRecord { "condition": "hsm_unavailable" | "anchor_failed" | "deposit_failed" | "chain_gap" | "capture_outage" | "clock_anomaly" | "other", "detected_at": "", "affected_interval": { "start": "", "end": "" }, "affected_modules": ["PRL", "LOC", "KAL", "SYS"], "items_queued": , "staging_digest": "", "disposition": "recovered" | "gap_declared" | "under_review", "human_reviewer_ref": "", "narrative": "" } ContinuityRecords declare gaps rather than concealing them. A declared gap is itself evidence of good faith; an undeclared gap is an integrity violation. -01 required that Evidence Items generated during an HSM outage be retroactively cross-signed by a backup HSM within four hours, while also requiring that every item be signed before emission and that all signing occur in an HSM. No conforming implementation could satisfy all three. -02 resolves this: on HSM unavailability the Node MUST fail closed for evidence emission, queue source events in an encrypted staging area, commit to the queue via staging_digest in a ContinuityRecord signed by a standby HSM or offline key, and emit the queued items with their original timestamp and a recorded_at reflecting actual emission when signing capability returns. Items MUST NOT be back-dated in recorded_at, and the ContinuityRecord MUST remain in the chain permanently. 5.10.5. BridgingRecord See Section 8.4. 5.10.6. CoverageAttestation { "period_start": "", "period_end": "", "modules": ["PRL", "LOC", "KAL"], "sources": [ { "source_system": "", "event_classes": ["", ...], "in_scope": , "expected_count": , "submitted_count": , "seq_range_start": "", "seq_range_end": "", "reconciliation": "matched" | "variance_explained" | "variance_unexplained", "variance_narrative": "" } ], "exclusions": [ { "description": "", "basis": "" } ], "attestor_ref": "", "attestor_role": "", "attestation_text": "", "attestor_signature": "" } The Coverage Attestation is the mechanism by which an institution makes an explicit, signed, anchored, non-repudiable claim about completeness. It is REQUIRED at least once per calendar quarter per active module for RBIP-Core, and its evidence_id SHOULD be referenced in the coverage_ref of every Bundle Core formed during the attested period. Section 1.3, N1 applies in full: a Coverage Attestation is a claim, not a proof. Its function is to convert an omission from an invisible act into a false statement by a named officer, which is an examinable and, in most jurisdictions, sanctionable act. Implementations MUST NOT present the presence of a Coverage Attestation as cryptographic proof of completeness, and the Auditor API MUST NOT return a status of VERIFIED on the basis of coverage claims alone. ------------------------------------------------------------------------ 6. Protocol Workflow 6.1. Evidence Generation Step 1 -- Event Capture: The RBIP Node receives an event from a source system via Section 7.1. The Node MUST record source_system and, where the source provides one, source_seq, for later coverage reconciliation. Step 2 -- Classification and Field Split: The Node determines payload_mode and partitions fields into inline and commitment sets per Section 5.3. Step 3 -- Commitment Construction: For each commitment-mode field, generate a fresh salt of at least 32 octets under HSM control and compute the commitment per Section 5.1.5. Compute fields_root. Store (path, value, salt) in the institution's disclosure store, under the same protection as subject keys. Step 4 -- Inline Digest: Where data_fields is present, serialize canonically and compute data_digest. Step 5 -- Chain Linkage: Retrieve the item_digest of the most recently committed item in this module chain for this institution and set prev_digest to that value. For the genesis item use the all-zero digest. The Node MUST serialize chain-head updates so that two concurrent items cannot claim the same predecessor. Step 6 -- Item Digest: Serialize the full Evidence Item with signature and signature_cose omitted. Compute item_digest. Step 7 -- Signing: Produce a detached signature over the same canonical bytes per Section 5.1.6, using an HSM-held key valid at timestamp. Step 8 -- Emission: Persist the signed item atomically, advance the chain head, and only then acknowledge the source system. If persistence fails, the Node MUST NOT acknowledge, and MUST NOT advance the chain head. 6.2. Bundle Formation Step 1 -- Collection: Collect items per the configured bundling policy. Where no items are available and the heartbeat interval has elapsed, form a heartbeat bundle per Section 5.4.4. Step 2 -- Ordering: Order items per Section 5.4.1. Step 3 -- Manifest: Build the Bundle Manifest and compute manifest_digest. Step 4 -- Merkle Root: Compute merkle_root over the ordered item_digest values per Section 5.1.4. Step 5 -- Core Formation: Populate the Bundle Core, including prev_core_digest and bundle_seq. Compute core_digest. The Bundle Core is immutable from this point. Step 6 -- Core Signing: Produce bundle_signature per Section 5.1.6. Step 7 -- Log Append: Append core_digest to the Bundle Log and record the new log_root. 6.3. Archival Deposit Step RBIP mandates no specific provider. Conforming implementations MAY use any registration agency or repository that issues a globally resolvable, persistent identifier and that commits to long-term retrievability independent of the depositing institution. Step 1 -- Artifact Assembly: Assemble the Bundle Artifact per Section 5.4.3, with the PAR in its initial state (Section 6.6), and with the manifest included, encrypted, or omitted per Section 10.5. Step 2 -- Metadata: Deposit metadata conforming to [DataCite4.5] or the provider's equivalent: * title: an institution-neutral title that does not encode module names or event types. RECOMMENDED form: "RBIP Evidence Bundle - " * creator: institution legal name and LEI * publicationYear: the year of interval_end * resourceType: "Dataset" * description: MUST be limited to schema_version, alg_suite, core_digest, and interval. It MUST NOT include module lists, event type names, or item counts where Section 10.5 applies. * relatedIdentifier: the identifier of the preceding bundle -01 required the description to name the modules and item counts; see Section 10.4 and Section 10.5. Step 3 -- Identifier Recording: Record the assigned identifier in the PAR. The Bundle Core is not modified. Step 4 -- Resolution Check: The Node SHOULD re-resolve the identifier within 30 minutes and record the outcome in the PAR. Deposit failure MUST produce a ContinuityRecord with condition "deposit_failed". Deposit failure MUST NOT block anchoring. In -01, the anchor input depended on the DOI, so a deposit failure changed the anchored value; in -02 the two layers are independent and either can complete first. 6.4. Anchoring and Timestamping RBIP mandates no specific anchoring platform. A conforming anchoring system MUST provide a publicly retrievable commitment, a proof artifact sufficient for offline verification, and a stated finality property. Step 1 -- Anchor Input: Compute, using the digest of the bundle's algorithm suite: anchor_input = HASH( LP("RBIP-ANCHOR-v2") || LP(alg_suite) || LP(institution_id) || LP(core_digest_raw) ) where core_digest_raw is the raw octet digest, not its hex encoding. The -01 construction, sha256(bundle_digest || doi_uri_bytes), is withdrawn: it used unprefixed concatenation, and it made the anchor depend on an identifier that -01 itself allowed to be null or to arrive later. Where the log root is anchored instead of, or in addition to, individual bundles (Section 5.5), the same construction is used with LP("RBIP-LOGROOT-v2") as the domain separator and the raw log root in place of core_digest_raw. Step 2 -- Submission: Submit anchor_input to the anchoring service. The service MUST return an anchor reference and a proof artifact sufficient for a verifier holding only anchor_input and the public system's data to confirm the commitment offline. Step 3 -- State Tracking: Set the anchor state to "pending" and record submitted_at. Step 4 -- Finality Evaluation: Evaluate the finality policy (Section 6.5) on each observation. When satisfied, set the state to "attested" and record the observed time, reference, and proof digest. Step 5 -- PAR Update and Re-deposit: Update the PAR and deposit a new version of the Bundle Artifact. The Bundle Core, core_digest, merkle_root, and manifest_digest MUST be byte-identical to the previous version. A deposit whose bundle_core differs from a previously deposited version of the same bundle_id is an integrity violation. Multiple anchors for the same core_digest, on different systems, are permitted and RECOMMENDED for high-value bundles such as period-end PRL snapshots. The PAR carries an array. 6.5. Anchor States and Finality Policy -01 required "at least 6 block confirmations" and applied that requirement to proof-of-work and proof-of-stake systems alike. Confirmation depth is not a meaningful finality measure on systems with explicit finality, and six confirmations is not equivalent across systems with different security budgets. -02 replaces the fixed count with a declared policy. An institution MUST publish, at the endpoint of Section 7.5, a finality policy for each anchoring system it uses: { "system": "", "rule": "confirmations" | "finalized_checkpoint" | "calendar_attestation" | "tsa_token", "parameter": "", "max_latency": "", "rationale": "" } Anchor states: pending: Submitted, finality not yet satisfied. An implementation MUST NOT present a pending anchor as final, MUST NOT return "VERIFIED" for a bundle whose only anchor is pending, and MUST expose the pending state in every interface that reports the bundle. attested: The finality policy is satisfied and the proof verifies. failed: The anchor did not reach attested state within max_latency, or the proof failed to verify. A failed anchor MUST produce a ContinuityRecord with condition "anchor_failed" and MUST trigger re-anchoring of the same, unmodified core_digest. Anchor latency, defined as the interval from interval_end to the attested time, MUST be exposed through the Auditor API. Systematic growth in anchor latency is the observable signature of the T6 residual risk and SHOULD be monitored by verifiers. 6.6. Permanence Attestation Record The PAR replaces the -01 Triple-Layer Permanence Attestation. It is mutable by design, is versioned, and never affects core_digest. { "par_version": "rbip-02", "bundle_id": "", "core_digest": "", "alg_suite": "", "par_seq": , "archival": [ { "identifier": "", "resolver": "", "provider": "", "deposited_at": "", "state": "deposited" | "pending" | "failed", "manifest_disposition": "included" | "encrypted" | "withheld" } ], "anchors": [ { "system": "", "anchor_ref": "", "submitted_at": "", "observed_at": "", "observed_time": "", "state": "pending" | "attested" | "failed", "finality_rule": "", "proof_digest": "", "proof_location": "" } ], "publication": [ { "kind": "internet-draft" | "standard" | "other", "reference": "", "date": "" } ], "par_signature": "" } The name change from TLPA is deliberate. "Triple-layer" described a fixed count; a bundle may have one archival deposit and three anchors, or two deposits and one anchor. The property that matters is that independent layers commit to the same core_digest, not that there are exactly three. Where an institution wishes to describe a bundle as having triple-layer permanence, it MUST have at least one archival entry in state "deposited", at least one anchor in state "attested", and at least one publication entry. 6.7. Evidence Verification and Audit A verifier MUST be able to complete the following using only the deposited artifact, the public anchoring system, published key material, and any manifest or proofs it is authorized to receive. Step 1 -- Retrieve Artifact: Resolve the persistent identifier and retrieve the Bundle Artifact. Where more than one version exists, retrieve the latest and confirm that its bundle_core is byte-identical to every earlier version. Step 2 -- Recompute core_digest: Canonicalize bundle_core with bundle_signature omitted and recompute the digest under alg_suite. It MUST equal the PAR's core_digest. Step 3 -- Verify Anchors: For each anchor in state "attested", recompute anchor_input per Section 6.4, Step 1 and verify the proof artifact against the anchoring system. Confirm the observed time and confirm the finality rule was met. Record the earliest attested observed time as the upper bound on the bundle's existence. Step 4 -- Verify Manifest and Root: Obtain the manifest, decrypt if required, confirm its digest equals manifest_digest, and recompute merkle_root from its item_digest entries per Section 5.1.4. Confirm it equals the Bundle Core's merkle_root. Step 5 -- Verify Items: For each item of interest, recompute item_digest from the item with signatures omitted, confirm it matches the manifest entry, verify the detached signature against key material valid at the item's timestamp per Section 7.5, and verify the inclusion proof under merkle_root. Step 6 -- Verify Chains: Confirm each item's prev_digest equals the item_digest of its predecessor in the same module chain. Confirm each Bundle Core's prev_core_digest equals the predecessor's core_digest and that bundle_seq increments by one. Step 7 -- Verify Log Consistency: Verify inclusion of core_digest under a log root, and where the verifier holds a previously observed log root, verify consistency between them per [RFC9162], Section 2.1.4. Step 8 -- Verify Continuity: Confirm that a bundle exists for every heartbeat interval in the examined period, or that a ContinuityRecord declares and explains each gap. Step 9 -- Assess Coverage: Retrieve the Coverage Attestations covering the period and reconcile source sequence ranges against submitted counts. Report unexplained variance. Per Section 1.3, N1, this step does not establish completeness and MUST NOT be reported as if it did. Verification outcome MUST be reported per Section 7.2.3 and MUST distinguish integrity results from coverage results. An item is INTEGRITY_VERIFIED if and only if Steps 1 through 8 succeed for it. No verification result asserts completeness or correctness. 6.8. Integrity Violation Handling The following are integrity violations: a broken item chain; a broken bundle chain; a bundle_seq gap; a merkle_root that does not match the manifest; a core_digest that differs between deposited versions of the same bundle_id; an anchor whose proof fails to verify; a missing heartbeat with no ContinuityRecord; and a signature verified against a key that was revoked before the item's timestamp. An RBIP Node, or any agent operating on its behalf, MUST NOT automatically remediate an integrity violation. It MUST NOT regenerate, re-sign, re-anchor, back-fill, or reorder evidence in response to a detected violation. Automated systems MAY detect, alert, quarantine, and open a review; the disposition of an integrity violation MUST be recorded by a human reviewer through a ContinuityRecord. This prohibition exists because automated repair of an integrity failure is indistinguishable, in the resulting record, from the tampering the protocol is designed to detect. It is consistent with the treatment of chain integrity violations in [I-D.reilly-sentinel-protocol] and with the blast radius constraints of [I-D.reilly-cbpi]. Detected violations MUST be reported to the institution's chief compliance officer immediately, and to the relevant supervisory authority within the period required by that authority. -01 specified 24 hours; -02 does not set a protocol-level deadline for external reporting, because the applicable period is set by law and varies, and a protocol document is not the correct place to state a supervisory deadline. ------------------------------------------------------------------------ 7. Interfaces and APIs All RBIP endpoints MUST be served over TLS 1.3 [RFC8446] or later. Requests MUST carry a JWS-signed JWT [RFC7519] bearer token. Mutual TLS [RFC8705] is REQUIRED for the Auditor API. 7.1. Internal Bank Systems Interface Base URL: https:///v2/ 7.1.1. Submit Evidence Event POST /events Request: { "module": "PRL" | "LOC" | "KAL" | "SYS", "event_type": "", "occurred_at": "", "payload_mode": "inline" | "commitment" | "mixed", "data_fields": { ... }, "commit_fields": ["", ...], "metadata": { "source_system": "", "source_seq": "" } } commit_fields names the fields the Node MUST convert to commitments. The Node MUST reject a submission that places a field listed as mandatory-commitment in Section 5.3 outside commit_fields. Response 202 Accepted: { "evidence_id": "", "item_digest": "", "accepted_at": "", "bundle_seq_expected": } Returning item_digest is new in -02; it lets the source system retain an independent record of what was committed. Response 400: { "error": "", "detail": "" } with codes INVALID_EVENT_TYPE, MISSING_REQUIRED_FIELD, SCHEMA_VIOLATION, COMMITMENT_POLICY_VIOLATION, UNSUPPORTED_ALG_SUITE. Response 503: returned when the Node is failed closed under Section 5.10.4. The body MUST identify the open ContinuityRecord. A source system receiving 503 MUST NOT treat the event as evidenced. The endpoint MUST be idempotent with respect to an Idempotency-Key header carrying a UUID. A repeat with the same key MUST return 200 with the original evidence_id and item_digest. 7.1.2. Query Evidence Item GET /events/{evidence_id} 7.1.3. Query Module Chain GET /modules/{module}/chain?from_id=&limit= 7.1.4. Bundle Status GET /bundles/{bundle_id} Returns the Bundle Core, the current PAR, and anchor states. 7.1.5. List Bundles GET /bundles?module=&start=
&end=
&page= 7.2. Regulator / Auditor API Base URL: https:///audit/v2/ Mutual TLS is REQUIRED. Client certificates MUST be pre-registered and bound to an authorization identifier. Every request MUST produce an AccessRecord (Section 5.10.1). 7.2.1. Get Bundle GET /bundles/{bundle_id} Returns bundle_core, par, and manifest where the requester is authorized for it. Commitment-mode values are not returned. 7.2.2. Get Inclusion Proof GET /bundles/{bundle_id}/proof/{evidence_id} { "evidence_id": "", "bundle_id": "", "leaf_digest": "", "leaf_index": , "tree_size": , "proof_path": ["", ...], "merkle_root": "", "core_digest": "", "par": { ... } } proof_path carries sibling digests in the order required by [RFC9162], Section 2.1.3. -01 carried a direction label per step; with the [RFC9162] construction, direction is determined by leaf_index and tree_size, and an explicit label that disagrees with them is a source of implementation divergence. Verifiers MUST derive direction from leaf_index and tree_size. 7.2.3. Verify Range POST /verify/range { "module": "PRL" | "LOC" | "KAL" | "SYS" | "all", "from": "", "to": "" } Response: { "integrity_status": "INTEGRITY_VERIFIED" | "CHAIN_GAP" | "DIGEST_MISMATCH" | "ANCHOR_INVALID" | "ANCHOR_PENDING" | "CHAIN_STALE" | "SIGNATURE_INVALID", "coverage_status": "ATTESTED_MATCHED" | "ATTESTED_VARIANCE_EXPLAINED" | "ATTESTED_VARIANCE_UNEXPLAINED" | "NOT_ATTESTED", "bundle_count": , "heartbeat_count": , "item_count": , "first_bundle_seq": , "last_bundle_seq": , "log_root": "", "log_size": , "anomalies": [ { "type": "", "bundle_id": "", "detail": "" } ] } integrity_status and coverage_status are separate fields, and no combined status is defined. -01 returned a single VERIFIED value, which invited the reading that a verified chain was a complete one. 7.2.4. Consistency Proof POST /verify/consistency { "from_size": , "to_size": } Returns the [RFC9162] consistency proof between the two log states, and MAY additionally return a bulk subtree proof per [I-D.reilly-plants-bulk-subtree-proofs] where both parties support it. 7.2.5. Selective Disclosure POST /disclose { "bundle_ids": ["", ...], "evidence_ids": ["", ...], "field_paths": ["", ...], "legal_basis": { "authority": "", "instrument": "", "instrument_date": "" } } The Node MUST verify the client certificate against the pre-registered authorization list, MUST create and commit a DisclosureRecord (Section 5.10.2) before releasing anything, and MUST then return, for each disclosed field, the tuple (path, value, salt) together with an inclusion proof under fields_root. Response: { "disclosure_ref": "", "disclosed": [ { "evidence_id": "", "path": "", "value": , "salt": "", "commitment": "", "proof_path": ["", ...], "fields_root": "" } ] } Disclosure of a salt permits the recipient to confirm the value against the commitment. It also permits that recipient, and anyone to whom the recipient passes the salt, to confirm a guess at the value forever afterwards. Salts MUST therefore be released only for the specific fields disclosed, MUST NOT be reused across fields, and recipients SHOULD be notified of this property. -01 directed that a disclosure request be recorded as a KAL CaseEscalation. That would file supervisory access records inside the AML case chain, corrupting both. Disclosure records are SYS evidence in -02. 7.2.6. Access Log GET /access-log?from=
&to=
Returns AccessRecords for the period. These are ordinary SYS evidence and are bundled and anchored like any other. 7.3. Public Transparency API An institution MAY expose a public interface. Section 10.5 constrains what it may contain, and an institution subject to report confidentiality law MUST complete the review described in Section 10.4 before enabling it. 7.3.1. Anchor Summary GET /anchors?period= { "institution_id": "", "period": "", "bundle_count": , "heartbeat_interval": "", "latest": { "bundle_seq": , "core_digest": "", "anchor_state": "attested" | "pending", "observed_time": "", "identifier": "" } } The response MUST NOT be broken down by module, and MUST NOT include event type names or per-module counts. -01's public endpoint was parameterized by module and returned per-module bundle counts, which for the KAL module is a disclosure channel; see Section 10.4. 7.3.2. Verify Public Anchor GET /verify/{bundle_id} Returns core_digest, anchor state, observed time, and the persistent identifier. Returns no evidence content, no manifest, and no module breakdown. 7.4. Webhook and Notification Interface Events: bundle_formed, bundle_deposited, anchor_pending, anchor_attested, anchor_failed, deposit_failed, chain_gap_detected, heartbeat_missed, coverage_attested, key_revoked, continuity_opened, continuity_closed. Payloads MUST be signed per Section 5.1.6 and MUST carry a nonce and an issued-at time. Subscribers MUST verify the signature and MUST reject replays. Webhook delivery is a notification channel only; a subscriber MUST NOT treat a webhook as evidence, and MUST verify against the Auditor API or the deposited artifact. 7.5. Key Discovery and Revocation -01 required verifiers to check signatures against "the institution's published RBIP signing key certificate" without specifying where it is published or how revocation is learned, which left the signature check unimplementable by an independent party. -02 defines discovery. An institution MUST serve: GET /.well-known/rbip per [RFC8615], returning: { "institution_id": "", "schema_versions": ["rbip-02", "rbip-01"], "conformance_class": "RBIP-Core" | "RBIP-Audited" | "RBIP-Transparent", "modules": ["PRL", "LOC", "KAL", "SYS"], "alg_suites": ["", ...], "heartbeat_interval": "", "jwks_uri": "", "revocation_uri": "", "audit_api": "", "finality_policies": [ { ... per Section 6.5 ... } ], "log_roots_uri": "" } The JWK Set [RFC7517] MUST include, for each key, "kid", "alg", and the RBIP members "rbip_not_before", "rbip_not_after", and "rbip_state" with value "active", "retired", "revoked", or "compromised", plus "rbip_state_effective" where the state is revoked or compromised. Keys MUST NOT be removed from the set when retired or revoked; historical evidence requires them. The revocation registry MUST return the same state information in a form that can be retrieved without retrieving the whole key set, MUST be signed, and MUST carry an issued-at time and a next-update time. Every state transition MUST also appear as a KeyLifecycleRecord (Section 5.10.3) in the evidence chain, so that the revocation history is itself anchored and cannot be revised silently. A verifier MUST evaluate a signature against the key state as of the signed item's timestamp, not as of verification time. ------------------------------------------------------------------------ 8. Cryptographic Requirements 8.1. Digest Algorithms The digest algorithm is determined by alg_suite (Section 5.1.2). Digest values MUST carry the algorithm label as specified in Section 5.1.2; a bare hex string is not a conforming digest value. MD5 and SHA-1 MUST NOT be used. Truncated digests MUST NOT be used. 8.2. Signing and Key Management Signature algorithms are determined by alg_suite. Where RSA is used under rbip-suite-5, the modulus MUST be at least 3072 bits; -01 permitted 2048, which is below current guidance for records intended to remain verifiable for multi-decade retention periods, and rbip-suite-5 is retained only for institutions with an existing RSA-bound HSM estate. All signing keys MUST have: o A validity period not exceeding two years, recorded in the JWK Set and in a KeyLifecycleRecord. o A documented rotation procedure, exercised at least annually. o Discoverable public key material per Section 7.5. o Separation of duties: the key used for Evidence Items, the key used for Bundle Cores, and the key used for Coverage Attestations by an attesting officer MUST be distinct. -01 permitted the item and bundle keys to be the same key; -02 requires separation, because a single key makes an officer attestation indistinguishable from routine node output. 8.3. HSM Requirements All RBIP signing operations, and all salt generation, MUST occur within a hardware security module validated to FIPS 140-3 Level 3 or higher, or to an equivalent scheme such as Common Criteria EAL4+ against a comparable protection profile. -01 required FIPS 140-2 Level 3; validations under that scheme have been transitioning to historical status, and new deployments cannot reasonably be required to procure against a closed scheme. An institution operating an existing FIPS 140-2 Level 3 estate MAY continue to use it and MUST record the fact in its conformance statement. Requirements: o Key generation MUST occur within the HSM. o Private key material MUST NOT exist in plaintext outside the HSM boundary. o Backup MUST use HSM-to-HSM wrapping; plaintext export is PROHIBITED. o Signing operations MUST be logged by the HSM, and those logs MUST be evidenced as SYS AccessRecords or an equivalent registered event type. -01 directed that HSM logs be archived "per RBIP KAL", which would place operational logs in the AML case chain. o A standby HSM SHOULD be provisioned. Where none is available, Section 5.10.4 governs the outage. 8.4. Algorithm Migration and Bridging Records Evidence is retained for decades; algorithms are not. -01 asserted cryptographic agility on the strength of a schema_version field but defined no migration mechanism, so an institution changing digest algorithm would have produced a chain that no single verifier could traverse. Migration proceeds as follows: Step 1: The institution publishes the successor suite at the endpoint of Section 7.5 with a stated activation time. Step 2: At the activation boundary, the institution emits a SYS BridgingRecord: { "from_alg_suite": "", "to_alg_suite": "", "activation_at": "", "last_core_digest_from": "", "last_bundle_seq": , "restated_digest_to": "", "log_root_from": "", "log_root_to": "", "signature_from": "", "signature_to": "" } Step 3: The first bundle under the new suite sets prev_core_digest to restated_digest_to and references the BridgingRecord. Normative constraints: o Historical evidence MUST NOT be re-hashed, re-signed, or re-anchored under the new suite. The BridgingRecord binds the old chain to the new one; it does not replace the old chain. o A BridgingRecord MUST be dual-signed, under both suites, by keys valid at activation_at. o A BridgingRecord MUST be anchored under both suites where the anchoring system supports both. o Where a digest algorithm is subsequently broken, the BridgingRecord anchored before the break is what preserves the evidentiary value of pre-break evidence: it establishes that a specific old-suite digest was already committed at a time when the algorithm was not known to be broken. Institutions SHOULD therefore migrate ahead of, not after, published attacks. The same construction is used for signature suite migration, including migration to a post-quantum or composite suite. Institutions holding evidence with retention horizons beyond the expected life of classical signatures SHOULD adopt rbip-suite-pq-2 or a successor composite suite, so that evidence remains verifiable under either component. ------------------------------------------------------------------------ 9. Security Considerations 9.1. Integrity Is Not Completeness The most significant residual risk in RBIP is T8, selective non-submission. Every cryptographic mechanism in this document operates on evidence that reached the RBIP Node. An institution that routes inconvenient events around the Node produces a trail that is internally perfect. Auditors MUST treat an RBIP trail as evidence about submitted events and MUST corroborate scope by independent means, including reconciliation against source system sequence ranges, transaction volume analysis, and examination. See Section 1.3, N1 and Section 5.10.6. 9.2. Chain Integrity Item chains and the bundle chain are the primary mechanism against insertion, deletion, and reordering. Chain head advancement MUST be serialized; concurrent writers that read the same head produce a fork that presents as a digest mismatch. Implementations SHOULD use a single-writer chain head per module chain with durable, monotonic sequencing. 9.3. Anchor Finality An anchor bounds existence time from above only, and only to the confidence of the anchoring system. A verifier MUST NOT treat a pending anchor as evidence of time. Reorganization depth, validator finality rules, and timestamp-manipulation tolerances of the chosen system are properties of that system, not of RBIP, and MUST be stated in the finality policy. Anchoring to a single system creates a dependency on that system's continued operation and its historical data remaining retrievable; institutions with long retention horizons SHOULD anchor to more than one. 9.4. Key Compromise On compromise: revoke immediately and publish the state through Section 7.5; emit a KeyLifecycleRecord signed by a successor or offline root key; open a ContinuityRecord; and treat every item signed between the earliest possible compromise time and the revocation as requiring corroboration. Evidence signed before the compromise window retains its value, which is precisely why revocation is evaluated against the item timestamp and not against verification time. Cross-certification by an independent auditor, as -01 required for all items signed by a compromised key, is RECOMMENDED for items in the compromise window and is not required for items outside it. 9.5. HSM Failure See Section 5.10.4. The Node fails closed for evidence emission. Failing open, and signing outside the HSM, is PROHIBITED. 9.6. Denial of Service Internal, Auditor, and public interfaces MUST implement rate limiting. Proof generation over large ranges is computationally asymmetric in the requester's favour and is a plausible resource exhaustion vector; implementations SHOULD bound range size per request, offer consistency proofs in preference to per-item proofs for large ranges, and apply per-authorization quotas. Rate limiting MUST NOT be applied so as to prevent a supervisory authority from completing an examination; a rate-limited supervisory request MUST be queued and served, not rejected. 9.7. Cryptographic Agility See Section 8.4. Agility is a migration procedure, not a version field. 9.8. Supply Chain RBIP Node software MUST be built through a verifiable pipeline with pinned dependencies, and each release MUST publish a software bill of materials and a signed build attestation. The digest of the deployed build SHOULD be recorded in a SYS event at deployment, so that the software that produced a given range of evidence is itself identified in the evidence. 9.9. Automated Remediation Automated repair of integrity violations is PROHIBITED; see Section 6.8. Where an institution operates autonomous agents in its compliance estate, those agents MUST operate under an oversight model in which actions affecting evidence integrity are not automatable, consistent with [I-D.reilly-cbpi] and [I-D.reilly-sentinel-protocol]. 9.10. Salt Disclosure Releasing a salt during selective disclosure permanently removes the brute-force protection for that field for anyone holding the salt. Salts MUST be unique per field per item so that disclosure is confined to the disclosed field. Salt stores MUST be protected at the level of subject encryption keys, and their destruction is part of erasure (Section 10.3). ------------------------------------------------------------------------ 10. Privacy and Confidentiality Considerations 10.1. Personal Data Personal data MUST NOT appear in cleartext in any Evidence Item, Bundle Manifest, or Bundle Artifact. Personal data MUST be carried as commitment-mode fields per Section 5.1.5, or, where the value must be recoverable by the institution from the evidence store itself, encrypted with AEAD under a per-subject key held in the HSM [NIST-SP-800-38D]. Unsalted digests of identifiers are not a privacy mechanism; see Section 5.1.5 and T10. Implementations MUST NOT describe an unsalted identifier digest as pseudonymization or anonymization. 10.2. Selective Disclosure RBIP separates cryptographic structure from payload. A verifier can establish existence, integrity, ordering, and time using only structure. Payload values are released only through the evidenced procedure of Section 7.2.5, which produces a permanent record of who received what, when, and under what authority. 10.3. Erasure Erasure obligations, including those under GDPR Article 17 [GDPR], are in tension with an append-only evidence chain. RBIP addresses the tension by making the erasable material separable from the structure: o Cleartext values, per-field salts, and per-subject keys live in the institution's disclosure store, never in the anchored structure. o Erasure is performed by destroying the salts and keys for the subject. The commitments, digests, roots, and anchors remain and continue to verify; the values become unrecoverable, and unguessable, because the salt is gone. o Erasure MUST itself be evidenced as a SYS event recording the subject reference as a commitment, the scope, the legal basis, and the destruction time. The erasure record MUST NOT contain the erased values. This is the property named Erasure-Compatible Permanence in [I-D.reilly-aigov], and salted commitments are what make it work. The -01 design could not achieve it: destroying a key does not make an unsalted identifier digest unrecoverable, because the digest never depended on the key. Institutions MUST maintain a documented mapping between evidence retention periods and applicable regulatory retention requirements, and MUST NOT erase material whose retention is mandated, whatever the erasure request. Nothing in this section is legal advice, and the tension it describes is not fully resolved by any technical measure. 10.4. Report Confidentiality This section is new in -02 and describes a defect in -01 with legal consequences. In several jurisdictions it is unlawful to disclose the existence of a suspicious activity report, or information that would reveal its existence, to any person outside a defined circle. In the United States this obligation arises under 31 U.S.C. 5318(g)(2) and implementing regulations including 31 CFR 1020.320(e) [SAR-CONF]. Comparable prohibitions apply in other jurisdictions. The -01 design placed such information into publicly deposited artifacts in three ways: the event type name SARSubmission appeared in the Bundle Manifest, which -01 embedded in full inside the deposited bundle; the -01 deposit metadata description was required to name the modules included and the item counts; and the -01 public interface returned per-module bundle counts by period. A third party observing the deposited record could infer that a report was filed by an institution in a period, and, with the manifest, count them. Conforming -02 implementations: o MUST use commitment mode for every field of a ReportSubmission event, and MUST NOT use an event type name that identifies the filing as a suspicious activity report (Section 5.9.4). o MUST NOT include module names, event type names, or item counts in publicly retrievable deposit metadata where this section applies. o MUST NOT return per-module counts or module-parameterized responses from the public interface (Section 7.3.1). o MUST withhold or encrypt the Bundle Manifest for any bundle containing KAL evidence (Section 10.5). o MUST obtain a documented legal review before enabling any public interface, and MUST record the review reference in the conformance statement. Where an institution cannot satisfy these constraints, it MUST maintain a separate institution chain for KAL evidence whose artifacts are deposited under access-controlled terms, or MUST NOT evidence KAL events under RBIP at all. Evidencing them in a way that discloses their existence is worse than not evidencing them. 10.5. Minimization of Deposited Metadata A publicly retrievable Bundle Artifact MUST contain no more than: the Bundle Core, the PAR, and, where permitted, the manifest. The manifest MUST be withheld or encrypted where the bundle contains KAL evidence, where evidence_id values or per-module counts would reveal supervisory or personal information, or where Section 10.4 applies. Where withheld, manifest_disposition in the PAR MUST record it, and the institution MUST serve the manifest to authorized verifiers under Section 7.2. Institutions SHOULD consider that bundle size, cadence, and modules_included are themselves a side channel. An institution subject to Section 10.4 MAY replace modules_included in the deposited Bundle Core with a salted commitment to the module set, disclosing the set to authorized verifiers only; where it does so, the commitment MUST be constructed per Section 5.1.5 with path "/modules_included". 10.6. Cross-Border Transfer Deposit with an archival provider located in another jurisdiction constitutes a cross-border transfer. Because commitment-mode fields carry no values and no salts, a conforming -02 artifact transfers commitments and structure only. Institutions MUST ensure that salts, per-subject keys, and cleartext disclosure stores remain within the required jurisdiction, and SHOULD document the transfer analysis in the conformance statement. ------------------------------------------------------------------------ 11. Compliance with Regulatory Standards This section is informational. Conformance to this document is not a compliance finding, and institutions MUST obtain independent legal and compliance advice for their jurisdictions. Statements below describe what RBIP evidences, not what it satisfies; -01 framed several of these as satisfaction, which Section 1.3, N3 now forbids. 11.1. Basel III / Basel IV The PRL module evidences LCR and NSFR inputs and outputs through ReserveSnapshot, the methodology and assumptions of internal stress tests through LiquidityStressTest, and officer certification through ReserveAttestation. Where an institution makes Pillar 3 disclosures, the public interface can evidence that the disclosed figures were committed at the time claimed, subject to Section 10.5. 11.2. Sarbanes-Oxley Section 404 The LOC and SYS modules evidence the operation of controls over material financial decisions: what was decided, by which model version and artifact digest, in what order, and committed at what time. Coverage Attestations evidence management's own statement of scope. RBIP does not evaluate control design or effectiveness. 11.3. Bank Secrecy Act and AML The KAL module evidences customer due diligence records, the operation of transaction monitoring, and the fact and timing of regulatory filings. Section 10.4 governs how filing evidence is handled; an implementation that evidences filings in a manner that discloses their existence is non-conforming regardless of its cryptographic properties. 11.4. DORA [DORA2022] requires ICT risk management, detection, and incident registers. SYS ContinuityRecords provide a tamper-evident incident register with declared, non-repudiable gaps, which is directly responsive to Articles 9, 10, 12, and 17. Article 17 reporting timelines are set by the regulation; see Section 6.8. 11.5. MiCA For issuers subject to [MiCA2023] Title III, PRL ReserveSnapshot and ReserveAttestation evidence the composition and certification of reserves on the cadence the issuer operates. Public reserve attestation is a case where the public interface is intended, and Section 10.5 permits full manifest deposit for a PRL-only chain with no KAL evidence. 11.6. ISO/IEC 42001:2023 For AI-based credit scoring or monitoring, LOC UnderwritingDecision and KAL TransactionMonitorAlert carry model identifier, version, and artifact digest, which together identify the exact artifact that produced a decision. -01 carried a version string only, which does not identify an artifact. Where governance records for the AI system itself are required, [I-D.reilly-aigov] defines the AI System Record and Governance Event Record, which compose with RBIP evidence by reference. ------------------------------------------------------------------------ 12. Implementation Guidance 12.1. Reference Implementation Notes A conforming Node requires: o Event adapters for the institution's systems of record. Adapters SHOULD expose a monotonic source sequence, because coverage reconciliation (Section 5.10.6) is otherwise unverifiable. o A canonicalizer implementing [RFC8785]. General-purpose JSON serializers MUST NOT be used. Implementations SHOULD test canonicalization against the [RFC8785] test vectors and MUST test that omitted members and empty-string members produce different digests, since conflating them is the specific error -01 embedded. o A Merkle implementation per Section 5.1.4 with inclusion and consistency proofs. Implementations SHOULD test against [RFC9162] vectors and MUST include a test that rejects leaf-duplication roots. o An HMAC-based commitment layer per Section 5.1.5 with salt generation and storage under HSM control. o A deposit client for the chosen archival provider. o An anchoring client producing offline-verifiable proofs, with state tracking per Section 6.5. o An HSM integration layer. PKCS#11 [PKCS11] is the common abstraction. o A well-known endpoint, JWK Set, and revocation registry per Section 7.5. o Recursive self-evidencing: the Node's own access, key, disclosure, coverage, and continuity events are SYS evidence and go through the same pipeline. Interoperability testing SHOULD include cross-implementation verification: an independent implementation, given only a deposited artifact and public data, completing Section 6.7 Steps 1 through 8. An implementation that cannot be verified by an independent implementation is not conforming, whatever its internal tests report. 12.2. Deployment Topologies 12.2.1. Single Node One Node processes all modules with one institution chain. Simplest to verify. Suitable for smaller institutions. 12.2.2. Module-Separated Nodes Each module runs on an isolated Node with separate HSM-backed keys, submitting to a shared Bundle Aggregator that maintains the institution chain and Bundle Log. Recommended where KAL evidence must be segregated under Section 10.4, in which case KAL SHOULD have its own institution chain, its own Bundle Log, and its own deposit terms. 12.2.3. Consortium Several institutions submit core_digest values to a shared aggregator operated by a utility or central bank, which maintains a combined log and co-anchors many institutions in one commitment. This amortizes anchoring cost and provides cross-institution ordering. The aggregator MUST NOT receive manifests, salts, or cleartext, and each institution MUST retain its own chain and remain independently verifiable if the consortium ceases to operate. 12.3. Anchoring Cost Anchoring every bundle individually is the simplest design and the most expensive. Anchoring the Bundle Log root per heartbeat interval covers every bundle appended since the last anchor with one commitment, at the cost of one additional inclusion proof during verification. Institutions SHOULD anchor log roots routinely and anchor individual core_digest values for high-significance bundles such as period-end PRL snapshots and Coverage Attestations. ------------------------------------------------------------------------ 13. IANA Considerations -01 requested three media types with incomplete registration templates. This section provides complete templates per [RFC6838] and adds two registries so that suites and event types can be extended without revising this document. 13.1. Media Type application/rbip-evidence-item+json Type name: application Subtype name: rbip-evidence-item+json Required parameters: version Optional parameters: module Encoding considerations: binary; UTF-8 JSON per [RFC8259] Security considerations: See Section 9 and Section 10 of this document. Instances may carry commitments to personal data. Interoperability considerations: Canonicalization per [RFC8785] is required for digest reproducibility. Published specification: This document Applications that use this media type: Banking compliance evidence systems, supervisory and audit tooling Fragment identifier considerations: As for application/json Additional information: Deprecated alias names: N/A Magic number(s): N/A File extension(s): .rbip-item.json Macintosh file type code(s): N/A Person & email address to contact for further information: Lawrence John Reilly Jr. Intended usage: COMMON Restrictions on usage: None Author: Lawrence John Reilly Jr. Change controller: IETF Provisional registration: No 13.2. Media Type application/rbip-bundle+json As Section 13.1, with subtype name rbip-bundle+json and file extension .rbip-bundle.json. Instances carry a Bundle Artifact per Section 5.4.3. Security considerations include Section 10.4 and Section 10.5: an instance may be publicly deposited, and its metadata content is constrained accordingly. 13.3. Media Type application/rbip-par+json As Section 13.1, with subtype name rbip-par+json and file extension .rbip-par.json. Instances carry a Permanence Attestation Record per Section 6.6. This registration replaces the -01 request for application/rbip-tlpa+json, which was never registered; if -01's request is pending at the time of processing, it should be withdrawn in favour of this one. 13.4. RBIP Algorithm Suite Registry IANA is requested to create the "RBIP Algorithm Suites" registry. Registration policy: Specification Required Fields: Suite Label, Digest Algorithm, Signature Algorithm, Status, Reference Initial contents: the suites of Section 5.1.2, all with a reference to this document. Suite labels beginning "rbip-suite-" are reserved for this registry. Registrations MUST specify one digest and one signature algorithm, or an explicit composite construction. 13.5. RBIP Event Type Registry IANA is requested to create the "RBIP Event Types" registry. Registration policy: Specification Required Fields: Module, Event Type, Payload Mode Constraint, Reference Initial contents: the event types of Sections 5.7 through 5.10, with their payload mode constraints, referencing this document. The -01 event type SARSubmission is registered as obsolete, with a note that it is superseded by ReportSubmission for the reason given in Section 10.4. ------------------------------------------------------------------------ 14. Acknowledgments The author thanks the financial cryptography, transparency logging, auditing, and digital preservation communities, whose work on tamper-evident logs, public timestamping, and persistent identifiers this protocol builds upon. The Merkle log construction used here is that of Certificate Transparency, and the correction in this revision consists largely of using it as specified rather than as paraphrased. The specification was deposited under a persistent identifier on 13 September 2025 (DOI: 10.5281/zenodo.17114424), publicly timestamped, and submitted to the IETF on 27 September 2025 as draft-reilly-banking-integrity-00, revised as -01 on 21 March 2026, and revised as this -02 on 3 September 2026. See Section 1.4 for what that record does and does not establish. ------------------------------------------------------------------------ 15. References 15.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload Option", RFC 7797, DOI 10.17487/RFC7797, February 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . [FIPS-140-3] National Institute of Standards and Technology, "Security Requirements for Cryptographic Modules", FIPS PUB 140-3, March 2019, . [FIPS-180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015, . [FIPS-202] National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS PUB 202, August 2015, . [ISO17442] International Organization for Standardization, "Financial services -- Legal entity identifier (LEI)", ISO 17442. [ISO9362] International Organization for Standardization, "Banking -- Banking telecommunication messages -- Business identifier code (BIC)", ISO 9362. [ISO4217] International Organization for Standardization, "Codes for the representation of currencies", ISO 4217. 15.2. Informative References [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [PKCS11] OASIS PKCS 11 TC, "PKCS #11 Cryptographic Token Interface Base Specification Version 3.0", OASIS Standard, June 2020, . [FIPS-204] National Institute of Standards and Technology, "Module-Lattice-Based Digital Signature Standard (ML-DSA)", FIPS PUB 204, August 2024, . [NIST-SP-800-38D] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST SP 800-38D, November 2007, . [DataCite4.5] DataCite Metadata Working Group, "DataCite Metadata Schema Documentation for the Publication and Citation of Research Data and Other Research Outputs", Version 4.5, DOI 10.14454/g9e5-6293, 2022, . [GDPR] European Parliament and Council, "Regulation (EU) 2016/679 (General Data Protection Regulation)", OJ L 119/1, April 2016. [DORA2022] European Parliament and Council, "Regulation (EU) 2022/2554 on Digital Operational Resilience for the Financial Sector (DORA)", OJ L 333/1, December 2022. [MiCA2023] European Parliament and Council, "Regulation (EU) 2023/1114 on Markets in Crypto-Assets (MiCA)", OJ L 150/40, June 2023. [SAR-CONF] United States, "Reports by financial institutions of suspicious transactions", 31 U.S.C. 5318(g)(2), and "Reports by banks of suspicious transactions -- Confidentiality of SARs", 31 CFR 1020.320(e). [USC-35-102] United States, "Conditions for patentability; novelty", 35 U.S.C. 102(a)(1). [OTS] Todd, P., et al., "OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin", . Used as the initial anchoring implementation for this specification. Any anchoring system satisfying Sections 6.4 and 6.5 is conforming. [RBIP-Whitepaper] Reilly, L.J., "Reilly Banking Integrity Protocol (RBIP): Ensuring Permanent and Regulator-Verifiable Audit Trails", 13 September 2025, DOI 10.5281/zenodo.17114424, . [I-D.reilly-rem-protocol] Reilly, L.J., "Reilly EternaMark (REM) Protocol: Dual-Layer Digital Permanence via Archival Deposit and Public Timestamping", Work in Progress, draft-reilly-rem-protocol, . [I-D.reilly-cbpi] Reilly, L.J., "Cognitive Behavioral Provenance and Integrity (CBPI) for Autonomous AI Agents", Work in Progress, draft-reilly-cbpi, . [I-D.reilly-sentinel-protocol] Reilly, L.J., "Reilly Sentinel Protocol (RSP)", Work in Progress, draft-reilly-sentinel-protocol, . [I-D.reilly-aigov] Reilly, L.J., "Verifiable AI Governance and Data Privacy Records", Work in Progress, draft-reilly-aigov, . [I-D.reilly-plants-bulk-subtree-proofs] Reilly, L.J., "Bulk Subtree Consistency Proofs", Work in Progress, draft-reilly-plants-bulk-subtree-proofs, . [I-D.reilly-cts] Reilly, L.J., "Cognitive Trust Stack (CTS): AI Behavioral Provenance Framework", Work in Progress, draft-reilly-cts, . ------------------------------------------------------------------------ Appendix A. Detailed Changes from -01 Each entry states the -01 text, the defect, and the -02 treatment. A.1. Corrections Required for Verifiability A.1.1. Merkle construction. -01 Section 5.2 required odd-count trees to duplicate the final leaf and attributed the convention to [RFC9162], Section 2.1, which contains no such requirement. Duplication permits distinct leaf sequences to share a root. -02 Section 5.1.4 specifies the [RFC9162] construction with leaf and node domain separators and prohibits duplication. A.1.2. Merkle leaf input. -01 built the tree over data_digest values, which covered only data_fields. Item envelopes were outside the root, so timestamps, chain links, module, and evidence_id could be altered without changing merkle_root, and two items with equal payloads produced equal leaves. -02 uses item_digest over the full canonical item. A.1.3. prev_digest. -01 defined it three ways in Sections 3, 6.1, and 6.6. -02 Section 5.2 defines it once as the predecessor's item_digest. A.1.4. Signature construction. -01 required a JWS Compact Serialization over the canonical item, computed with the signature member set to empty string, and separately said the signature excluded that member. -02 Section 5.1.6 uses a detached, unencoded-payload JWS over the canonical item with the member omitted, and Section 5.1.1 states that omission and empty string are not equivalent. A.1.5. Anchor payload. -01 Section 6.4 anchored sha256(bundle_digest || doi_uri_bytes): unprefixed concatenation, dependent on an identifier that -01 permitted to be null. -02 Section 6.4 anchors a domain-separated, length-prefixed function of core_digest alone. A.1.6. Anchor circularity. -01 Section 6.4, Step 5 recomputed bundle_digest after anchoring and re-deposited, guaranteeing that the anchored digest did not match the deposited artifact. -02 separates the immutable Bundle Core from the mutable PAR (Sections 5.4 and 6.6), so re-deposit never changes core_digest. A.1.7. Merkle proof direction labels. -01 returned a direction per proof step; under [RFC9162] direction derives from leaf_index and tree_size, and a disagreeing label is a divergence source. -02 Section 7.2.2 removes the labels. A.2. Privacy Corrections A.2.1. Unsalted identifier hashes. -01 specified unsalted SHA-256 over applicant, underwriter, customer, destination, document, and report identifiers and treated the result as privacy protection. Such identifiers are low entropy and recoverable. -02 Section 5.1.5 requires salted, keyed commitments with per-field salts of at least 32 octets under HSM control. A.2.2. Plaintext officer identities. -01 Section 10.1 prohibited plaintext personal data while Sections 5.4.1 and 5.4.3 required officer names and employee identifiers in plaintext. -02 Section 5.3 resolves the conflict: identity is a commitment, role is inline. A.2.3. Report existence disclosure. -01 deposited manifests naming SARSubmission events, required deposit metadata to name modules and counts, and returned per-module counts publicly. -02 Section 10.4 addresses this, Section 5.9.4 renames the event, and Sections 6.3, 7.3.1, and 10.5 constrain deposited and public metadata. A.2.4. Erasure. -01 achieved erasure by destroying a per-subject key, which does not affect unsalted digests computed independently of that key. -02 Section 10.3 ties erasure to destruction of salts and keys, making commitments unrecoverable. A.2.5. Zero-knowledge cross-reference. -01 T5 referred to zero-knowledge proofs "per Section 7.3", which specified none. -02 removes the dangling reference and specifies the commitment and selective disclosure mechanisms actually used. A.3. Assurance Additions A.3.1. Evidence Coverage Attestation (Sections 1.3, 5.10.6, 9.1). A.3.2. Heartbeat bundles (Section 5.4.4). A.3.3. SYS module, giving a home to the access, key, disclosure, and continuity records -01 required but never defined (Section 5.10). A.3.4. Anchor states and declared finality policy, replacing the fixed six-confirmation rule that -01 applied to proof-of-stake systems where it has no meaning (Section 6.5). A.3.5. Bundle Log with inclusion and consistency proofs, addressing equivocation (Sections 5.5 and 7.2.4). A.3.6. Prohibition on automated remediation (Section 6.8). A.3.7. HSM outage handling that a conforming implementation can actually satisfy; -01's three requirements were mutually unsatisfiable (Section 5.10.4). A.3.8. Key discovery and revocation, without which -01's signature verification step could not be performed by an independent party (Section 7.5). A.3.9. Conformance classes and a mechanical checklist (Section 4.4, Appendix B). A.4. Agility and Data Model A.4.1. Algorithm suites and IANA registry (Sections 5.1.2, 13.4). A.4.2. Bridging records for hash and signature migration (Section 8.4). A.4.3. FIPS 140-3 in place of FIPS 140-2 (Section 8.3); RSA minimum raised from 2048 to 3072 bits (Section 8.2); key separation of duties (Section 8.2). A.4.4. Monetary values as structured objects rather than parsed strings (Section 5.6). A.4.5. Model artifact digests added to LiquidityStressTest and UnderwritingDecision, so that model traceability claims rest on an artifact rather than a version string (Sections 5.7.2, 5.8.2, 11.6). A.4.6. prior_valuation_item added to CollateralRevaluation (Section 5.8.4). A.4.7. attests_to_digest added to ReserveAttestation (Section 5.7.3). A.5. Claims Narrowed A.5.1. -01 stated that its permanence layers produce properties "that no existing proprietary compliance product achieves simultaneously". Withdrawn: unverifiable. A.5.2. -01 stated that its timestamp "PRECEDES any subsequent implementation, derivative work, or regulatory mandate" and that disputes "must contend with three independently operated systems". Withdrawn and replaced by Section 1.4, which claims only that the fact and date of a disclosure are independently checkable, per [I-D.reilly-rem-protocol] and [USC-35-102]. A.5.3. -01 Section 11 described RBIP as satisfying regulatory requirements. -02 Section 11 describes what RBIP evidences, and Section 1.3, N3 prohibits the stronger framing. A.5.4. -01 returned a single VERIFIED status covering chain and anchor state together. -02 separates integrity_status from coverage_status and defines an ANCHOR_PENDING value, so that a pending anchor cannot be reported as verified (Section 7.2.3). A.6. Editorial A.6.1. The [RFC9162] reference in -01 credited authors who did not write it. Corrected, and [RFC6962] added as informative. A.6.2. [ISO17442], [ISO9362], and [ISO4217] were cited in -01 schemas but absent from its reference list. Added. A.6.3. IANA templates completed per [RFC6838]; the -01 tlpa media type is superseded by rbip-par+json (Section 13). A.6.4. The schema $id was hosted under a domain associated with a separate project; moved (Section 5.2). A.6.5. -01 set an external regulator notification deadline of 24 hours as a protocol requirement. Removed; the applicable period is set by law (Section 6.8). ------------------------------------------------------------------------ Appendix B. Conformance Checklist An implementation claiming conformance SHOULD publish this checklist completed. Each line is answered yes or no; a claim of RBIP-Core with any REQUIRED line answered no is not conforming. Core: B-1 Canonicalization per [RFC8785], with omitted-vs-empty test B-2 Merkle per Section 5.1.4, with leaf-duplication rejection test B-3 item_digest as Merkle leaf and as prev_digest link B-4 Detached signatures per Section 5.1.6 B-5 Salted field commitments per Section 5.1.5, salts under HSM B-6 Bundle Core immutable after formation; core_digest never recomputed B-7 Bundle chain with prev_core_digest and contiguous bundle_seq B-8 Heartbeat bundles at the declared interval B-9 Bundle Log with inclusion and consistency proofs B-10 Anchor input per Section 6.4, Step 1 B-11 Anchor states with published finality policy B-12 PAR versioned separately from Bundle Core B-13 SYS AccessRecord, DisclosureRecord, KeyLifecycleRecord, ContinuityRecord, CoverageAttestation implemented B-14 Fail closed on HSM unavailability B-15 No automated remediation of integrity violations B-16 /.well-known/rbip, JWK Set, revocation registry B-17 Signature evaluation against key state at item timestamp B-18 FIPS 140-3 Level 3 HSM, or declared 140-2 legacy estate B-19 Key separation: item, bundle, attestor B-20 rbip-suite-1 supported Audited: B-21 Auditor API with mTLS and pre-registered authorizations B-22 Inclusion and consistency proofs served B-23 Selective disclosure gated on a committed DisclosureRecord B-24 integrity_status and coverage_status reported separately Transparent: B-25 Public interface with no module breakdown or event type names B-26 Section 10.4 legal review completed and referenced Independent verification: B-27 A second, independently written implementation has completed Section 6.7, Steps 1 through 8, against a deposited artifact ------------------------------------------------------------------------ Appendix C. Migration from rbip-01 Evidence Evidence produced under rbip-01 MUST NOT be re-hashed, re-signed, re-anchored, or rewritten to conform to this revision. Doing so would destroy the property the evidence exists to provide. An institution moving from -01 to -02: C-1 Continues to serve -01 evidence under -01 rules, and lists "rbip-01" in schema_versions at the endpoint of Section 7.5. C-2 Emits a SYS BridgingRecord (Section 8.4) at the transition, with from_alg_suite naming the -01 construction, and records in its narrative that the -01 Merkle roots were computed with leaf duplication where that was the case. C-3 Sets prev_core_digest of the first -02 bundle to the -01 bundle_digest of the last -01 bundle, and records that value in the BridgingRecord. C-4 Publishes, for verifiers, the fact that -01 roots used a different leaf input and construction, so that a verifier does not apply -02 rules to -01 evidence and report a false mismatch. Verifier tooling MUST select its construction from schema_version, not from configuration. C-5 Does not represent -01 evidence as satisfying the -02 privacy requirements. Where -01 evidence carries unsalted identifier digests, the institution SHOULD assess re-identification exposure of the already-deposited artifacts, since deposit is by design not reversible, and SHOULD document the assessment. This is the one -01 defect that a revision cannot repair retroactively: material already deposited under a persistent identifier stays deposited. C-6 Where -01 evidence was publicly deposited with manifests naming SARSubmission events, obtains legal advice promptly. Section 10.4 describes the obligation; the remedy for evidence already deposited is a matter for counsel and the relevant authority, not for this document. ------------------------------------------------------------------------ Author's Address Lawrence John Reilly Jr. REM Technologies & Consulting, LLC Email: lreilly250@gmail.com IETF Datatracker: https://datatracker.ietf.org/person/lreilly250@gmail.com This document is deposited and timestamped per Section 1.4: * Persistent identifier: DOI 10.5281/zenodo.17114424 (deposited 2025-09-13) * Public timestamp via a proof-of-work anchoring system (2025-09-13) * IETF submission: draft-reilly-banking-integrity-00 (2025-09-27) * Revision -01: 2026-03-21 * This version (-02): 2026-09-03