Network Working Group L.J. Reilly Internet-Draft Independent Intended status: Standards Track 21 March 2026 Expires: 21 September 2026 Reilly Banking Integrity Protocol (RBIP) draft-reilly-banking-integrity-01 Abstract This document defines version 01 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 blockchain timestamping) with archival DOI issuance to produce permanent, tamper-evident records across three core domains: Proof-of-Reserves & Liquidity (PRL), Loan Origination & Collateral Chain (LOC), and KYC/AML Evidence Ledger (KAL). RBIP is designed to help financial institutions satisfy requirements from Basel III/IV, SOX, BSA/AML, DORA, MiCA, ISO/IEC 42001:2023, and other applicable regulations while preserving privacy, accountability, and auditability. This document and its foundational specification are protected under triple-layer digital permanence: (1) DOI archival via a persistent archival provider (DOI: 10.5281/zenodo.17114424, published September 13, 2025, initially archived at Zenodo); (2) blockchain timestamping via a public proof-of-work blockchain timestamping service (initially anchored via OpenTimestamps to the Bitcoin blockchain); and (3) IETF Internet-Draft submission (draft-reilly-banking-integrity-00, submitted September 27, 2025). This triple-layer permanence establishes cryptographically verifiable prior art with an immutable public timestamp predating any subsequent implementation, derivative work, or regulatory mandate. 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 21 September 2026. 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 . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Triple-Layer Permanence Declaration . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Design Overview . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Architecture and Modules . . . . . . . . . . . . . . . 8 4.2. Threat Model . . . . . . . . . . . . . . . . . . . . . 9 4.3. Trust Hierarchy . . . . . . . . . . . . . . . . . . . . 10 5. Data Model and Canonical Serialization . . . . . . . . . . 11 5.1. Evidence Item Structure . . . . . . . . . . . . . . . . 11 5.2. Evidence Bundle . . . . . . . . . . . . . . . . . . . . 13 5.3. Merkle Anchoring Structure . . . . . . . . . . . . . . 14 5.4. PRL Module Events . . . . . . . . . . . . . . . . . . . 15 5.5. LOC Module Events . . . . . . . . . . . . . . . . . . . 17 5.6. KAL Module Events . . . . . . . . . . . . . . . . . . . 19 6. Protocol Workflow . . . . . . . . . . . . . . . . . . . . . 21 6.1. Evidence Generation . . . . . . . . . . . . . . . . . . 21 6.2. Bundle Formation . . . . . . . . . . . . . . . . . . . 22 6.3. DOI Archival Step . . . . . . . . . . . . . . . . . . . 22 6.4. Blockchain Anchoring and Timestamping . . . . . . . . . 23 6.5. Triple-Layer Permanence Attestation . . . . . . . . . . 24 6.6. Evidence Verification and Audit . . . . . . . . . . . . 25 7. Interfaces and APIs . . . . . . . . . . . . . . . . . . . . 26 7.1. Internal Bank Systems Interface . . . . . . . . . . . . 26 7.2. Regulator / Auditor API . . . . . . . . . . . . . . . . 29 7.3. Public Transparency API . . . . . . . . . . . . . . . . 31 7.4. Webhook and Notification Interface . . . . . . . . . . 32 8. Cryptographic Requirements . . . . . . . . . . . . . . . . 33 8.1. Digest Algorithms . . . . . . . . . . . . . . . . . . . 33 8.2. Signing and Key Management . . . . . . . . . . . . . . 33 8.3. HSM Requirements . . . . . . . . . . . . . . . . . . . 34 9. Security Considerations . . . . . . . . . . . . . . . . . . 35 10. Privacy and Confidentiality Considerations . . . . . . . . 37 11. Compliance with Regulatory Standards . . . . . . . . . . . 38 12. Implementation Guidance . . . . . . . . . . . . . . . . . . 40 12.1. Reference Implementation Notes . . . . . . . . . . . . 40 12.2. Deployment Topologies . . . . . . . . . . . . . . . . 41 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 42 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 43 15. References . . . . . . . . . . . . . . . . . . . . . . . . 43 15.1. Normative References . . . . . . . . . . . . . . . . . 43 15.2. Informative References . . . . . . . . . . . . . . . . 45 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 46 ------------------------------------------------------------------------ 1. Introduction 1.1. Motivation Financial regulators and auditors require trustworthy, tamper- evident audit trails of banking operations. Conventional centralized logs and database snapshots are susceptible to undetectable alteration, retrospective deletion, or insider manipulation. High-profile failures -- from fraudulent reserve attestations to undocumented collateral substitution -- demonstrate that cryptographic guarantees are no longer optional; they are a structural prerequisite for systemic trust in financial infrastructure. Existing audit frameworks rely on periodic sampling, self-reported attestations, and trusted-third-party certifications. None of these mechanisms produce independently verifiable, continuous, tamper-evident records that auditors can validate without institutional cooperation. RBIP closes this gap by combining two orthogonal mechanisms: o Deep archival of evidence artifacts under persistent, globally resolvable identifiers (DOIs), ensuring permanent accessibility and citation permanence independent of any single institution. o Cryptographic anchoring of artifact digests to a public blockchain, establishing a chronologically ordered, tamper- evident ledger of events that cannot be rewritten without detectable proof-of-work invalidation. Together, these mechanisms produce audit trails that are permanent, tamper-evident, and regulator-verifiable -- properties that no existing proprietary compliance product achieves simultaneously and at open-protocol scale. 1.2. Scope RBIP is a protocol specification for the generation, archival, anchoring, and verification of banking integrity evidence. It does NOT prescribe any particular blockchain platform, DOI 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 Bundle formation, DOI archival, and blockchain anchoring workflows o Regulator, auditor, and public transparency APIs o Security, privacy, and regulatory compliance requirements RBIP does NOT cover: o Core banking transaction processing o Payment clearing and settlement protocols o Smart contract execution logic o Specific blockchain consensus mechanisms 1.3. Triple-Layer Permanence Declaration The RBIP specification is itself protected and timestamped under the author's Reilly EternaMark (REM) Protocol [I-D.draft-reilly-rem- protocol], applying triple-layer digital permanence: Layer 1 -- DOI Archival: The foundational RBIP whitepaper was published and DOI-archived at a persistent archival provider on September 13, 2025. The assigned DOI is permanently resolvable via the Handle System and indexed by DataCite and OpenAIRE: DOI: 10.5281/zenodo.17114424 URL: https://zenodo.org/records/17114424 NOTE: Zenodo (operated by CERN) was used as the initial archival provider for this specification. RBIP implementations MAY use any DataCite-member DOI registration agency or equivalent persistent identifier infrastructure (e.g., Zenodo, Figshare, institutional repositories, or national data archives). The requirement is a globally resolvable, persistent identifier -- not any specific platform. Layer 2 -- Blockchain Timestamping: The specification artifact was submitted to a public blockchain timestamping service, producing a cryptographic proof-of-existence attestation with a block timestamp that is immutable by design of proof-of-work consensus. This timestamp PRECEDES any subsequent regulatory mandate, derivative implementation, or competing claim. NOTE: OpenTimestamps anchored to the Bitcoin blockchain was used as the initial timestamping mechanism for this specification. RBIP implementations MAY use any public, proof-of-work blockchain with sufficiently deep finality (RECOMMENDED: 6+ confirmations) and a compatible open timestamping protocol. Other suitable implementations include Ethereum-based anchoring services, Hedera Hashgraph, or any IETF-compatible distributed timestamping mechanism conforming to [RFC3161]. The requirement is a publicly verifiable, tamper-evident chronological commitment -- not any specific blockchain platform. Layer 3 -- IETF Internet-Draft Submission: The protocol was submitted to the IETF as an Internet-Draft on September 27, 2025 (draft-reilly-banking-integrity-00), recorded in the IETF Datatracker at: https://datatracker.ietf.org/doc/draft-reilly-banking-integrity/ IETF submission timestamps are publicly logged, independently verifiable, and archived by the IETF document repository. The combination of these three independent, redundant archival and timestamping mechanisms constitutes triple-layer digital permanence. Any attempt to dispute authorship, priority, or provenance of this specification must contend with three independently operated, cryptographically verifiable systems. ------------------------------------------------------------------------ 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 This section defines terms used throughout this document. Evidence Item: The atomic unit of RBIP. A structured record capturing a discrete banking event, including cryptographic linkage to prior events. Analogous to a journal entry in a tamper-evident ledger. Evidence Bundle: A collection of Evidence Items aggregated for a defined interval (e.g., daily, hourly). Bundles are the unit of DOI archival and blockchain anchoring. Bundle Root Digest: A single SHA-256 (or SHA3-256) hash representing the Merkle root of all Evidence Items in a bundle. This is the value submitted to the blockchain anchoring service. DOI (Digital Object Identifier): A persistent, globally unique identifier assigned to a published artifact. RBIP uses DOIs to ensure long-term, institution- independent accessibility of Evidence Bundles. Blockchain Anchor: A transaction on a public blockchain that embeds or commits to the Bundle Root Digest, producing a tamper-evident proof-of- existence for the bundle. The transaction's block timestamp constitutes chronological proof that the bundle existed at or before that time. Any public, proof-of-work or proof-of-stake blockchain with sufficient finality and public verifiability (e.g., Bitcoin, Ethereum) MAY be used as the anchoring chain. Triple-Layer Permanence: The RBIP-defined property of an artifact that has been simultaneously (1) DOI-archived, (2) blockchain-timestamped, and (3) submitted to a public standards body. Each layer is independently verifiable and redundant. PRL (Proof-of-Reserves & Liquidity): The RBIP module capturing reserve attestations, liquidity stress test outcomes, and regulatory capital snapshots. LOC (Loan Origination & Collateral Chain): The RBIP module capturing the full lifecycle of loan events from application through default resolution. KAL (KYC/AML Evidence Ledger): The RBIP module capturing identity verification, transaction monitoring alerts, SAR filings, and AML case lifecycle events. Canonical Form: A deterministic, byte-for-byte reproducible serialization of an Evidence Item. RBIP mandates JCS (JSON Canonicalization Scheme) [RFC8785] for JSON serialization and CBOR Deterministic Encoding [RFC8949] for CBOR serialization. prev_digest: The SHA-256 digest of the immediately preceding Evidence Item in the same module chain. Creates an unforgeable chain linking all events in chronological order. evidence_id: A globally unique identifier for an Evidence Item, formatted as a UUID v4 [RFC9562] prefixed with the module code. Example: "PRL-550e8400-e29b-41d4-a716-446655440000" HSM (Hardware Security Module): A tamper-resistant hardware device used to generate, store, and manage cryptographic keys. RBIP REQUIRES HSM-backed key operations for bundle signing. RBIP Node: A software component deployed within a financial institution that implements the RBIP Evidence Generation, Bundling, and Anchoring workflows as specified in this document. Auditor Interface: The RBIP API endpoint exposed to authorized regulators and auditors for evidence retrieval, Merkle path verification, and anchor validation. ------------------------------------------------------------------------ 4. Design Overview 4.1. Architecture and Modules RBIP is composed of three cooperating compliance modules and a shared anchoring infrastructure layer: +-------------------------------------------------------------------+ | BANK CORE SYSTEMS | | (CBS, LOS, KYC Engine, AML Engine, Treasury Management System) | +-----------------------------------+-------------------------------+ | v +-------------------------------------------------------------------+ | RBIP EVIDENCE GENERATOR | | +------------------+ +-----------------+ +------------------+ | | | PRL Module | | LOC Module | | KAL Module | | | | (Reserves/Liq.) | | (Loan/Collat.) | | (KYC/AML Cases) | | | +--------+---------+ +--------+--------+ +--------+---------+ | | | | | | | +---------------------+---------------------+ | | | | | +------------v-----------+ | | | Bundle Aggregator | | | +------------+-----------+ | +-------------------------------- | --------------------------------+ | +----------------+----------------+ | | v v +------------------------------+ +------------------------------+ | DOI Archival Service | | Blockchain Anchoring Service | | (Any DataCite-member repo) | | (Any public PoW/PoS chain) | +------------------------------+ +------------------------------+ | | +-----------------+---------------+ | +-----------------v---------------+ | Triple-Layer Attestation Record | +-----------------+---------------+ | +--------+--------------+-----------+ | | | v v v +----------+--+ +---+------------------+ +----+------------------+ | Regulator/ | | Public Transparency | | Internal Compliance | | Auditor API | | API | | Dashboard | +-------------+ +----------------------+ +-----------------------+ The RBIP Node integrates with the financial institution's core systems via an event adapter layer. All events captured by the three modules flow through the Evidence Generator, are aggregated into Bundles, and simultaneously submitted to the DOI Archival and Blockchain Anchoring services. 4.2. Threat Model RBIP is designed to resist the following adversarial scenarios: T1 -- Retrospective Record Modification: An internal actor or attacker with database access attempts to alter historical event records. RBIP counters this via cryptographic chaining (prev_digest) and blockchain anchoring. Any modification breaks the digest chain and invalidates the blockchain anchor. T2 -- Record Deletion: An actor attempts to delete records covering a specific period. RBIP counters this via DOI archival (bundles are permanently archived) and Merkle proofs (absence of a bundle produces a gap in the chain that auditors can detect). T3 -- Event Reordering: An actor attempts to reorder events to alter the apparent sequence of decisions. RBIP counters this via prev_digest chaining and bundle timestamp ordering anchored to the blockchain. T4 -- Insider Collusion with Log Manager: Operators collude to replace archived bundles. RBIP counters this via the blockchain anchor: the bundle's Merkle root is publicly anchored, so any replacement bundle would produce a different root digest, invalidating the anchor. T5 -- Customer Data Exposure: An attacker or unauthorized auditor accesses sensitive PII or financial data via the RBIP APIs. RBIP counters this via selective encryption, role-based access control on the Auditor API, and zero-knowledge proofs for public transparency (MAY be implemented per Section 7.3). T6 -- Timestamp Fraud: An actor backdates an event to claim it occurred before a regulatory deadline. RBIP counters this via blockchain anchoring: the block timestamp is determined by network consensus and cannot be retroactively altered without invalidating the proof-of-work or proof-of-stake chain from that point forward. T7 -- API Replay Attacks: An attacker replays a valid API request to duplicate evidence submissions. RBIP counters this via idempotency keys, nonce requirements, and TLS with mutual authentication. 4.3. Trust Hierarchy RBIP defines the following trust hierarchy: Level 1 -- RBIP Node (Institution-Controlled): Generates Evidence Items. Trusted for event capture and serialization. MUST be deployed in an HSM-backed environment. Level 2 -- DOI Archival Provider: Archives Evidence Bundles. Trusted for long-term preservation. SHOULD be a DataCite-member repository or equivalent persistent identifier infrastructure that guarantees long-term, institution-independent accessibility. Level 3 -- Blockchain Anchoring Service: Embeds the Bundle Root Digest on-chain. Trusted for chronological ordering. MUST use a public blockchain with sufficient finality and publicly verifiable transaction history. At least 6 block confirmations are REQUIRED before treating an anchor as final (see Section 9.2). Level 4 -- Independent Auditors and Regulators: External verifiers. Trust nothing except the cryptographic proofs. RBIP enables trustless verification: auditors MUST be able to verify all claims without institutional cooperation. ------------------------------------------------------------------------ 5. Data Model and Canonical Serialization 5.1. Evidence Item Structure Each Evidence Item MUST be serialized in canonical JSON form per [RFC8785] (JCS -- JSON Canonicalization Scheme) before hashing. The canonical form MUST NOT include insignificant whitespace. Implementations supporting CBOR MUST use CBOR Deterministic Encoding [RFC8949] Section 4.2. Evidence Item JSON Schema: { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://rbip.blackseedlabs.io/schema/evidence-item-v1", "type": "object", "required": [ "evidence_id", "schema_version", "module", "event_type", "institution_id", "timestamp", "prev_digest", "data_digest", "data_fields", "signature" ], "properties": { "evidence_id": { "type": "string", "pattern": "^(PRL|LOC|KAL)-[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$", "description": "Module-prefixed UUID v4 [RFC9562] uniquely identifying this Evidence Item." }, "schema_version": { "type": "string", "const": "rbip-01", "description": "RBIP schema version. MUST be 'rbip-01' for this specification." }, "module": { "type": "string", "enum": ["PRL", "LOC", "KAL"], "description": "The RBIP module that generated this item." }, "event_type": { "type": "string", "description": "One of the event type strings defined in Sections 5.4-5.6." }, "institution_id": { "type": "string", "description": "LEI [ISO 17442] or BIC [ISO 9362] of the reporting institution." }, "timestamp": { "type": "string", "format": "date-time", "description": "ISO 8601 [RFC3339] UTC timestamp of event occurrence. MUST be UTC." }, "prev_digest": { "type": "string", "pattern": "^sha256:[0-9a-f]{64}$", "description": "SHA-256 hex digest of the preceding Evidence Item in this module chain. 'sha256:0000...0000' (64 zeros) for the genesis item." }, "data_digest": { "type": "string", "pattern": "^sha256:[0-9a-f]{64}$", "description": "SHA-256 hex digest of the canonical serialization of data_fields." }, "data_fields": { "type": "object", "description": "Module-specific event payload. Content varies by event_type (see Sections 5.4-5.6). MAY be encrypted per Section 10." }, "metadata": { "type": "object", "description": "Optional key-value metadata for indexing, tagging, and audit annotation.", "properties": { "regulatory_ref": { "type": "string" }, "jurisdiction": { "type": "string" }, "tags": { "type": "array", "items": { "type": "string" } }, "rbip_node_id": { "type": "string" }, "operator_id": { "type": "string" } } }, "signature": { "type": "string", "description": "Base64url-encoded JWS Compact Serialization [RFC7515] signing the canonical Evidence Item (excluding the signature field itself) using the institution's RBIP signing key." } } } The data_digest field MUST be computed over the canonical serialization of data_fields only (not the full Evidence Item). The signature field MUST be computed over the full canonical Evidence Item with signature set to the empty string "", ensuring the signed payload is stable and reproducible. 5.2. Evidence Bundle Evidence Items are aggregated into Evidence Bundles for DOI archival and blockchain anchoring. Bundles MAY be formed on a time-based schedule (e.g., every 15 minutes, hourly) or on an event-count threshold (e.g., every 1000 Evidence Items). Implementations MUST form and anchor at least one bundle per 24- hour UTC day per active module. Evidence Bundle JSON Schema: { "bundle_id": "", "schema_version": "rbip-01", "institution_id": "", "modules_included": ["PRL", "LOC", "KAL"], "interval_start": "", "interval_end": "", "item_count": , "merkle_root": "sha256:<64 hex chars>", "merkle_tree": [ { "index": 0, "evidence_id": "", "digest": "sha256:<...>" }, ... ], "prev_bundle_digest": "sha256:<64 hex chars>", "doi": "", "blockchain_anchor": { "chain": "", "tx_id": "", "block_height": , "block_timestamp": "", "proof": "" }, "bundle_digest": "sha256:<64 hex chars>", "bundle_signature": "" } The merkle_root field MUST be computed as the root of a binary Merkle tree [RFC9162] constructed from the ordered list of data_digest values of all Evidence Items in the bundle. Odd- count trees MUST duplicate the last leaf per the convention in [RFC9162] Section 2.1. The bundle_digest field MUST be computed over the canonical serialization of the entire bundle object with bundle_digest and bundle_signature set to empty strings "". 5.3. Merkle Anchoring Structure RBIP employs a binary Merkle tree for bundle integrity. The Merkle tree enables auditors to verify a single Evidence Item's inclusion in a bundle without downloading the full bundle, which is important for privacy-preserving partial disclosure. Merkle Proof Object (returned by Auditor API for single-item verification): { "evidence_id": "", "bundle_id": "", "leaf_digest": "sha256:<...>", "proof_path": [ { "direction": "left", "digest": "sha256:<...>" }, { "direction": "right", "digest": "sha256:<...>" }, ... ], "merkle_root": "sha256:<...>", "doi": "10.5281/zenodo.", "blockchain_anchor": { ... } } Auditors MUST be able to reconstruct the Merkle root from the leaf_digest and proof_path, then compare it against both the DOI- archived bundle and the blockchain anchor, without any involvement from the reporting institution. 5.4. PRL Module Events The PRL module captures reserve, liquidity, and capital adequacy events. All monetary amounts MUST be expressed as strings in the format " " (e.g., "1500000000.00 USD") to avoid floating-point precision errors. 5.4.1. ReserveSnapshot Triggered at a regular cadence (RECOMMENDED: daily at close-of- business) or on demand by a regulator request. data_fields: { "snapshot_type": "daily_close" | "regulator_requested" | "stress_triggered", "reporting_date": "", "reserve_assets": [ { "asset_class": "cash" | "hqla_l1" | "hqla_l2a" | "hqla_l2b" | "other", "asset_id": "", "market_value": " ", "haircut_pct": "", "post_haircut_value": " " } ], "total_hqla": " ", "lcr_ratio": "", "nsfr_ratio": "", "tier1_capital_ratio": "", "attestation_officer": "", "attestation_method": "automated_system" | "manual_review" | "external_audit" } 5.4.2. LiquidityStressTest data_fields: { "stress_scenario": "regulatory_standard" | "adverse" | "severely_adverse" | "institution_defined", "scenario_id": "", "horizon_days": , "baseline_lcr": "", "stressed_lcr": "", "survival_days": , "assumptions": [ { "parameter": "", "value": "", "basis": "" } ], "model_version": "", "run_timestamp": "" } 5.4.3. ReserveAttestation A signed certification by an authorized officer or external auditor that the ReserveSnapshot accurately reflects the institution's assets. data_fields: { "attests_to_snapshot_id": "", "attestor_name": "", "attestor_role": "CFO" | "CRO" | "external_auditor" | "regulator", "attestor_institution": "", "attestation_scope": "", "pgp_signature": "", "certificate_ref": "" } 5.5. LOC Module Events The LOC module tracks the full lifecycle of loan origination, underwriting, and collateral management. 5.5.1. LoanApplication data_fields: { "application_id": "", "application_date": "", "loan_type": "residential_mortgage" | "commercial_real_estate" | "auto" | "personal" | "sme" | "syndicated" | "other", "requested_amount": " ", "requested_term_months": , "applicant_hash": "sha256:", "origination_channel":"branch" | "digital" | "broker" | "wholesale", "jurisdiction": "" } NOTE: applicant_hash MUST be the SHA-256 of a stable internal applicant identifier. The identifier itself MUST NOT appear in any RBIP evidence record to comply with privacy requirements (Section 10). 5.5.2. UnderwritingDecision data_fields: { "application_id": "", "decision": "approved" | "declined" | "referred" | "conditionally_approved", "decision_date": "", "decision_rationale_hash": "sha256:", "approved_amount": " ", "approved_rate": "", "approved_term_months": , "conditions": [ { "condition_id": "", "description_hash": "sha256:<...>", "deadline": "" } ], "decision_model_id": "", "underwriter_hash": "sha256:" } 5.5.3. CollateralBinding data_fields: { "loan_id": "", "collateral_id": "", "collateral_type": "residential_property" | "commercial_property" | "securities" | "vehicle" | "equipment" | "cash_deposit" | "guarantee" | "other", "collateral_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.5.4. CollateralRevaluation data_fields: { "collateral_id": "", "prior_valuation": " ", "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": } 5.5.5. LoanDisbursement data_fields: { "loan_id": "", "disbursement_id": "", "disbursement_date": "", "amount": " ", "disbursement_method":"wire_transfer" | "ach" | "check" | "internal_credit", "destination_hash": "sha256:", "conditions_satisfied": [{ "condition_id": "", "satisfied_date": "" }] } 5.5.6. PaymentReceipt data_fields: { "loan_id": "", "payment_id": "", "payment_date": "", "amount": " ", "principal_component":" ", "interest_component": " ", "fees_component": " ", "days_past_due": , "payment_channel": "ach" | "wire" | "internal" | "cash" | "check" } 5.5.7. DefaultEvent / RecoveryEvent data_fields: { "loan_id": "", "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.6. KAL Module Events The KAL module captures identity lifecycle and AML case events. All personally identifiable information MUST be encrypted or hashed before inclusion in RBIP Evidence Items (see Section 10). 5.6.1. IdentitySubmission data_fields: { "submission_id": "", "submission_date": "", "customer_type": "individual" | "entity" | "correspondent_bank" | "pep", "identity_doc_type": "passport" | "national_id" | "drivers_license" | "entity_registration" | "other", "doc_hash": "sha256:", "liveness_check_result": "pass" | "fail" | "not_required", "submission_channel": "branch" | "digital_onboarding" | "api_partner" } 5.6.2. IdentityVerificationResult data_fields: { "submission_id": "", "verification_date": "", "result": "verified" | "failed" | "referred" | "escalated", "verification_method":"automated_ocr_biometric" | "manual_review" | "third_party_bureau" | "video_interview", "risk_score": , "risk_tier": "low" | "medium" | "high" | "prohibited", "sanctions_checked": , "pep_checked": , "adverse_media_checked": , "next_review_date": "" } 5.6.3. TransactionMonitorAlert data_fields: { "alert_id": "", "alert_generated_at": "", "alert_type": "structuring" | "layering" | "unusual_velocity" | "sanctions_match" | "pep_activity" | "high_risk_jurisdiction" | "other", "rule_id": "", "customer_hash": "sha256:", "transaction_count": , "aggregate_amount": " ", "risk_score": , "auto_disposition": "escalated_to_analyst" | "auto_cleared" | "pending" } 5.6.4. SARSubmission data_fields: { "sar_reference_hash": "sha256:", "submission_date": "", "jurisdiction": "", "fiu_agency": "FinCEN" | "NCA" | "FINTRAC" | "AUSTRAC" | "other", "activity_type": "money_laundering" | "terrorist_financing" | "fraud" | "structuring" | "other", "subject_count": , "reporting_period_start": "", "reporting_period_end": "", "filing_status": "initial" | "corrective" | "continuing" } 5.6.5. CaseEscalation data_fields: { "case_id": "", "escalation_date": "", "from_tier": "l1_analyst" | "l2_investigator" | "l3_senior", "to_tier": "l2_investigator" | "l3_senior" | "compliance_officer" | "law_enforcement", "escalation_reason": "", "linked_alert_ids": ["", ...], "linked_sar_hashes": ["sha256:<...>", ...] } 5.6.6. CaseClosure data_fields: { "case_id": "", "closure_date": "", "closure_outcome": "no_action" | "sar_filed" | "account_closed" | "law_enforcement_referral" | "regulatory_disclosure", "investigation_duration_days": , "disposition_hash": "sha256:" } ------------------------------------------------------------------------ 6. Protocol Workflow 6.1. Evidence Generation The following steps MUST be executed for every banking event captured by RBIP: Step 1 -- Event Capture: The RBIP Node receives an event notification from the core banking system via the Internal Bank Systems Interface (Section 7.1). Step 2 -- Field Population: The RBIP Node populates the Evidence Item structure per Section 5.1. Sensitive fields MUST be encrypted or hashed per Section 10 before populating data_fields. Step 3 -- Prev-Digest Linking: The RBIP Node retrieves the data_digest of the most recently committed Evidence Item in the same module chain and sets prev_digest to that value. For the genesis item, prev_digest MUST be set to "sha256:" followed by 64 zeros. Step 4 -- Data Digest Computation: Serialize data_fields to canonical JSON per [RFC8785]. Compute SHA-256 of the canonical bytes. Set data_digest. Step 5 -- Full Item Serialization: Serialize the full Evidence Item (with signature set to "") to canonical JSON per [RFC8785]. Step 6 -- Signing: Using the institution's RBIP signing key (HSM-backed, see Section 8.3), compute a JWS Compact Serialization [RFC7515] signature over the canonical Evidence Item bytes. Set the signature field. Step 7 -- Emission: Emit the signed Evidence Item to the Bundle Aggregator. The item MUST be persisted atomically before the event notification is acknowledged. 6.2. Bundle Formation Step 1 -- Collection: The Bundle Aggregator collects Evidence Items per the configured bundling policy (time-based or count-based). Step 2 -- Ordering: Items are sorted ascending by timestamp, then by evidence_id lexicographically to resolve same-timestamp ties. Step 3 -- Merkle Tree Construction: Construct a binary Merkle tree over the ordered list of data_digest values. Compute the merkle_root. Step 4 -- Bundle Digest: Serialize the full Bundle object (with bundle_digest and bundle_signature set to "") to canonical JSON per [RFC8785]. Compute SHA-256 to obtain bundle_digest. Step 5 -- Bundle Signing: Sign bundle_digest using the institution's RBIP bundle signing key (MAY be the same as the item signing key). Set bundle_signature. 6.3. DOI Archival Step RBIP does not mandate any specific DOI archival provider. Conforming implementations MAY use any DataCite-member DOI registration agency or equivalent persistent identifier infrastructure (e.g., institutional repositories, national data archives, or certified research data repositories). The requirement is a globally resolvable, persistent identifier that guarantees long-term accessibility independent of any single institution. Step 1 -- Submission: The RBIP Node submits the complete Evidence Bundle (excluding blockchain_anchor fields, which are populated post-anchoring) to the configured DOI archival provider via its published deposit API. Step 2 -- Metadata: The submission MUST include metadata conforming to the DataCite Metadata Schema 4.5 [DataCite4.5]: * title: "RBIP Evidence Bundle - - to " * creator: * publicationYear: * resourceType: "Dataset" * description: "RBIP-01 evidence bundle: events, merkle_root: " * identifier: * relatedIdentifier: Step 3 -- DOI Recording: Upon receiving the DOI from the archival provider, the RBIP Node updates the bundle record's doi field. Step 4 -- DOI Verification (RECOMMENDED): The RBIP Node SHOULD re-resolve the DOI via the Handle System (https://doi.org/) within 30 minutes to confirm successful archival before triggering blockchain anchoring. 6.4. Blockchain Anchoring and Timestamping RBIP does not mandate any specific blockchain platform or timestamping service. Conforming implementations MAY use any public, proof-of-work or proof-of-stake blockchain with sufficient finality guarantees, provided the anchoring produces a publicly verifiable, tamper-evident chronological commitment. Suitable implementations include, but are not limited to, open timestamping protocols compatible with public blockchains and distributed timestamping mechanisms conforming to [RFC3161]. Step 1 -- Anchor Data Preparation: Compute the Anchor Payload as: anchor_payload = sha256(bundle_digest || doi_uri_bytes) where || denotes concatenation. If doi is null (DOI archival failed), anchor_payload = bundle_digest. Step 2 -- Submission to Anchoring Service: Submit anchor_payload to the configured blockchain anchoring service. The service MUST return: a. A transaction identifier (tx_id) on the target chain. b. A proof artifact (e.g., a Merkle inclusion proof or timestamping proof blob) sufficient for independent offline verification. c. The block height and block timestamp upon confirmation. Step 3 -- Confirmation Waiting: RBIP REQUIRES at least 6 block confirmations on the target chain before treating the anchor as final. 10 confirmations are RECOMMENDED for high-value bundles (e.g., daily PRL snapshots). The required number of confirmations MAY be increased by institutional policy based on the finality characteristics of the chosen chain. Step 4 -- Anchor Recording: Record in blockchain_anchor: * chain: * tx_id: * block_height: * block_timestamp: * proof: Step 5 -- Bundle Update and Re-sign: Update the bundle with the populated blockchain_anchor fields. Recompute bundle_digest and bundle_signature over the updated canonical bundle. Archive the final bundle to the DOI provider as a new version. 6.5. Triple-Layer Permanence Attestation After Steps 6.3 and 6.4 are both complete, the RBIP Node MUST generate a Triple-Layer Permanence Attestation (TLPA) record for the bundle: { "tlpa_version": "rbip-01", "bundle_id": "", "bundle_digest": "sha256:<...>", "layer_1_doi": { "doi": "", "doi_url": "https://doi.org/", "archived_at": "", "provider": "" }, "layer_2_blockchain": { "chain": "", "tx_id": "", "block_height": , "block_timestamp": "", "proof_sha256": "sha256:", "confirmations_at_finality": }, "layer_3_ietf": { "draft_name": "draft-reilly-banking-integrity-01", "ietf_datatracker_url": "https://datatracker.ietf.org/doc/draft-reilly-banking-integrity/", "submission_date": "2025-09-27", "this_version_date": "2026-03-21" }, "tlpa_digest": "sha256:", "tlpa_signature": "" } The TLPA MUST be stored alongside the Evidence Bundle and MUST be returned to auditors upon request (Section 7.2). 6.6. Evidence Verification and Audit An independent auditor wishing to verify an Evidence Item MUST execute the following steps without institutional cooperation: Step 1 -- Retrieve TLPA: Obtain the TLPA for the relevant bundle from the Auditor API. Step 2 -- Resolve DOI: Resolve the DOI at https://doi.org/. Download the archived bundle. Verify bundle_digest matches the TLPA. Step 3 -- Verify Blockchain Anchor: Verify the timestamping proof artifact against the target blockchain using an appropriate verifier for the configured chain and protocol. Confirm the bundle_digest (or anchor_payload) is committed to the proof. Confirm the block_timestamp matches the TLPA. Step 4 -- Verify Merkle Proof: For each Evidence Item under investigation, request a Merkle proof from the Auditor API (Section 7.2). Recompute the Merkle root from the proof path and leaf digest. Confirm it matches the bundle's merkle_root. Step 5 -- Verify Digest Chain: For sequential Evidence Items in a module, verify that each item's prev_digest equals the SHA-256 of the preceding item's canonical serialization. Gaps or mismatches indicate tampering. Step 6 -- Verify Signatures: Verify the JWS signature on each Evidence Item using the institution's published RBIP signing key certificate. Verify the bundle_signature using the institution's bundle signing key certificate. An Evidence Item is VERIFIED if and only if all six steps succeed. Failure of any step MUST be reported to the institution's regulator as a potential integrity incident. ------------------------------------------------------------------------ 7. Interfaces and APIs All RBIP API endpoints MUST be served over TLS 1.3 [RFC8446]. All API requests MUST include a JWS-signed JWT [RFC7519] Bearer token in the Authorization header. Mutual TLS (mTLS) [RFC8705] is REQUIRED for the Regulator/Auditor API (Section 7.2). 7.1. Internal Bank Systems Interface The Internal Bank Systems Interface is a REST API exposed by the RBIP Node to the institution's core banking systems for event submission. Base URL: https:///v1/ 7.1.1. Submit Evidence Event POST /events Request Body: { "module": "PRL" | "LOC" | "KAL", "event_type": "", "occurred_at": "", "data_fields": { ... }, "metadata": { ... } } Response 202 Accepted: { "evidence_id": "", "accepted_at": "", "bundle_queue_position": } Response 400 Bad Request: { "error": "INVALID_EVENT_TYPE" | "MISSING_REQUIRED_FIELD" | "SCHEMA_VIOLATION", "detail": "" } The endpoint MUST be idempotent with respect to a client-supplied idempotency-key header (format: UUID v4). Duplicate submissions with the same idempotency key MUST return 200 OK with the original evidence_id. 7.1.2. Query Evidence Item GET /events/{evidence_id} Response 200 OK: Full signed Evidence Item JSON Response 404 Not Found: Item does not exist 7.1.3. Query Module Chain GET /modules/{module}/chain?from_id=&limit= Returns an ordered array of Evidence Items from from_id forward. Useful for continuous integrity monitoring by internal compliance. 7.1.4. Bundle Status GET /bundles/{bundle_id} Response 200 OK: Full Evidence Bundle JSON (including TLPA) Response 404 Not Found 7.1.5. List Bundles GET /bundles?module=&start=&end=&page= Returns paginated list of bundle summaries with doi and anchoring status. 7.2. Regulator / Auditor API The Regulator/Auditor API is exposed to authorized external parties. All connections MUST use mTLS [RFC8705]. Client certificates MUST be pre-registered with the RBIP Node and bound to an authorized auditor or regulatory identity. All access MUST be logged in a separate tamper-evident access log that is itself RBIP-evidenced. Base URL: https:///audit/v1/ 7.2.1. Get Evidence Bundle GET /bundles/{bundle_id} Returns the full Evidence Bundle including TLPA. Encrypted data_fields are returned in their encrypted form. The auditor MAY request selective decryption via a separate Selective Disclosure request (Section 7.2.5). 7.2.2. Get Merkle Proof GET /bundles/{bundle_id}/proof/{evidence_id} Returns: { "evidence_id": "", "bundle_id": "", "leaf_digest": "sha256:<...>", "proof_path": [ { "direction": "left"|"right", "digest": "sha256:<...>" }, ... ], "merkle_root": "sha256:<...>", "doi": "", "blockchain_anchor": { ... }, "tlpa": { ... } } 7.2.3. Verify Chain Integrity POST /verify/chain Request Body: { "module": "PRL" | "LOC" | "KAL", "from_date": "", "to_date": "" } Response: { "status": "VERIFIED" | "CHAIN_GAP_DETECTED" | "DIGEST_MISMATCH" | "ANCHOR_INVALID", "bundle_count": , "item_count": , "first_bundle_id": "", "last_bundle_id": "", "anomalies": [ { "type": "", "bundle_id": "", "detail": "" } ] } 7.2.4. Verify Blockchain Anchor POST /verify/anchor Request Body: { "bundle_id": "" } Response: { "bundle_id": "", "anchor_valid": , "chain": "", "tx_id": "", "block_height": , "block_timestamp": "", "confirmations": , "proof_verification": "VERIFIED" | "PENDING" | "FAILED", "doi_resolvable": } 7.2.5. Selective Disclosure Request POST /disclose Request Body: { "bundle_id": "", "evidence_ids": ["", ...], "fields": ["", ...], "purpose": "" } The RBIP Node verifies the requesting auditor's certificate against the pre-registered authorization list and, if authorized, decrypts and returns only the specifically requested fields. This request MUST itself be RBIP-evidenced as a KAL CaseEscalation event. 7.2.6. Audit Access Log GET /access-log?from=&to= Returns the tamper-evident log of all Auditor API access events for the specified period. The access log MUST itself be bundled and anchored per RBIP. 7.3. Public Transparency API Financial institutions MAY expose a Public Transparency API to provide limited, privacy-preserving assurance to the public that reserves and compliance operations are actively evidenced. This API MUST NOT expose any customer PII, sensitive financial data, or material non-public information. Implementations MUST conduct a legal review before enabling this interface. Base URL: https:///rbip/public/v1/ 7.3.1. Get Anchor Summary GET /anchors?module=&period= Returns: { "institution_id": "", "module": "PRL" | "LOC" | "KAL", "period": "", "bundle_count": , "latest_anchor": { "bundle_id": "", "block_height": , "block_timestamp": "", "doi": "", "merkle_root": "sha256:<...>" } } 7.3.2. Verify Public Anchor GET /verify/{bundle_id} Returns a minimal verification response confirming whether the specified bundle is anchored and DOI-archived. Does NOT return any evidence item content. 7.4. Webhook and Notification Interface RBIP Nodes SHOULD implement a webhook interface to notify registered subscribers (e.g., regulatory systems, compliance dashboards) of key events: Events triggering webhooks: o bundle_anchored -- bundle successfully blockchain-anchored o bundle_doi_issued -- bundle DOI successfully issued o tlpa_complete -- triple-layer permanence attestation complete o chain_gap_detected -- digest chain gap detected (CRITICAL) o anchor_failed -- blockchain anchoring failed (CRITICAL) o doi_archival_failed -- DOI archival failed (CRITICAL) Webhook payloads MUST be signed with a JWS [RFC7515] using the RBIP Node's webhook signing key. Subscribers MUST verify the JWS before processing. ------------------------------------------------------------------------ 8. Cryptographic Requirements 8.1. Digest Algorithms RBIP REQUIRES SHA-256 [FIPS-180-4] as the primary digest algorithm for all data_digest, prev_digest, bundle_digest, and merkle_root computations. SHA3-256 [FIPS-202] MAY be used as an alternative where required by institutional policy. If SHA3-256 is used, the digest strings MUST be prefixed with "sha3-256:" rather than "sha256:". MD5 and SHA-1 MUST NOT be used. 8.2. Signing and Key Management RBIP signing MUST use one of the following algorithms as specified in JSON Web Algorithms [RFC7518]: o RS256 (RSASSA-PKCS1-v1_5 with SHA-256) -- minimum RSA key size 2048 bits; 4096 bits RECOMMENDED o ES256 (ECDSA with P-256 and SHA-256) -- RECOMMENDED for new implementations due to smaller signature size o ES384 (ECDSA with P-384 and SHA-384) -- REQUIRED for high- assurance PRL module signatures o Ed25519 (EdDSA with Curve25519) -- MAY be used where supported All signing keys MUST have: o A defined validity period not exceeding 2 years o A documented key rotation procedure o A published X.509 certificate [RFC5280] or JWK Set [RFC7517] accessible to auditors for signature verification 8.3. HSM Requirements All RBIP signing key operations MUST be performed within a FIPS 140-2 Level 3 or higher HSM. The private key material MUST NEVER exist in plaintext outside the HSM boundary. HSM requirements: o Key generation MUST occur within the HSM o Key backup MUST use HSM-to-HSM key wrapping (key export in plaintext is PROHIBITED) o All signing operations MUST be logged by the HSM o HSM audit logs MUST be independently archived per RBIP KAL ------------------------------------------------------------------------ 9. Security Considerations 9.1. Digest Chain Integrity The prev_digest chain is the primary mechanism preventing undetected insertion, deletion, or reordering of Evidence Items. Implementations MUST maintain an unbroken chain within each module. Any detected gap MUST trigger an immediate alert and MUST be reported to the institution's Chief Compliance Officer and to the relevant regulator within 24 hours. 9.2. Blockchain Finality RBIP REQUIRES at least 6 block confirmations on the configured blockchain before treating an anchor as final. The precise number of confirmations required SHOULD be calibrated to the finality characteristics of the chosen chain (e.g., longer reorganization windows on chains with lower hash rate require more confirmations). Fewer confirmations risk chain reorganization that could invalidate the anchor. During the confirmation waiting period, bundles MUST be treated as pending and MUST NOT be represented to auditors as final. 9.3. Key Compromise Response If an RBIP signing key is compromised: (1) The institution MUST immediately revoke the key certificate. (2) The institution MUST publish a Key Compromise Event in the RBIP audit trail, anchored under the new key. (3) All Evidence Items signed with the compromised key MUST be cross-certified by a trusted third-party auditor. (4) The regulator MUST be notified within 72 hours. 9.4. HSM Failure Response If the HSM fails during evidence generation, the RBIP Node MUST queue events in an encrypted staging area and halt public API availability until the HSM is restored. Evidence Items generated during an HSM outage MUST be retroactively cross-signed by a backup HSM within 4 hours. 9.5. Denial of Service The Internal and Auditor APIs MUST implement rate limiting. The Auditor API MUST implement adaptive rate limiting that tightens limits when anomalous query patterns are detected. 9.6. Cryptographic Agility RBIP is designed for cryptographic agility. Implementations MUST support runtime algorithm configuration, enabling migration to post-quantum algorithms (e.g., ML-DSA [FIPS-204]) as they are standardized. All RBIP data structures include schema_version to facilitate future algorithm upgrades without breaking existing archived evidence. 9.7. Supply Chain Attacks RBIP Node software MUST be deployed with verifiable build pipelines. All RBIP software dependencies MUST be pinned to specific, audited versions. SBOM (Software Bill of Materials) generation MUST be part of the RBIP Node release process. ------------------------------------------------------------------------ 10. Privacy and Confidentiality Considerations 10.1. PII Prohibition Personally identifiable information (PII) as defined by GDPR [GDPR] and CCPA MUST NOT appear in any RBIP Evidence Item in plaintext. All PII MUST be either: (a) Replaced by a stable, institution-internal pseudonymous identifier hashed with SHA-256 (the "hash-and-reference" pattern), or (b) Encrypted using AES-256-GCM [NIST-SP-800-38D] with a per- customer encryption key managed in the HSM. 10.2. Selective Disclosure The RBIP data model separates the cryptographic structure (evidence_id, prev_digest, data_digest, merkle_root, blockchain anchor) from the payload (data_fields). Auditors can verify the existence, integrity, and chronological ordering of events using only the cryptographic structure, without accessing data_fields. This enables a "prove without reveal" disclosure model. 10.3. Right to Erasure Compliance GDPR Article 17 (Right to Erasure) creates a tension with RBIP's immutability requirements. RBIP addresses this as follows: o All PII in data_fields MUST be encrypted under per-subject keys. "Erasure" of a subject's data is achieved by destroying the subject's encryption key, rendering data_fields permanently indecipherable without breaking the cryptographic structure. o The cryptographic structure (digests, anchors) remains intact to preserve the audit chain. o Institutions MUST maintain a documented legal basis mapping between RBIP evidence retention periods and applicable regulatory retention requirements. 10.4. Cross-Border Data Transfer Evidence Bundles submitted to DOI archival providers (e.g., Zenodo/ CERN, Switzerland) constitute cross-border data transfer under GDPR. Institutions MUST ensure data_fields containing PII are encrypted before submission to DOI providers, and that the decryption keys never leave the institution's jurisdiction. Effectively, the DOI provider archives only ciphertext for PII-containing fields. ------------------------------------------------------------------------ 11. Compliance with Regulatory Standards This section describes how RBIP addresses specific regulatory requirements. This is informational guidance; institutions MUST seek independent legal and compliance counsel for their specific jurisdictions. 11.1. Basel III / Basel IV (BCBS) PRL Module directly addresses: o LCR (Liquidity Coverage Ratio) -- ReserveSnapshot captures HQLA values and LCR ratios required by BCBS 238. o NSFR (Net Stable Funding Ratio) -- ReserveSnapshot includes NSFR ratio. o Pillar 3 Disclosure -- RBIP Public Transparency API supports voluntary or mandatory Pillar 3 reserve disclosures. o Pillar 2 ICAAP -- LiquidityStressTest events archive the methodology, assumptions, and outcomes of internal stress tests. 11.2. Sarbanes-Oxley Act (SOX) Section 404 LOC and KAL Modules support SOX 404 compliance by providing: o Tamper-evident records of all material financial decisions (loan origination, underwriting, disbursement). o Cryptographic evidence that records existed at the time of decision (blockchain timestamp). o Non-repudiable officer attestations (ReserveAttestation). 11.3. Bank Secrecy Act (BSA) and AML KAL Module directly addresses BSA requirements: o 31 U.S.C. 5318(g) SAR filing obligations -- SARSubmission events archive metadata of SAR filings with cryptographic timestamps predating any regulatory inquiry. o Customer Due Diligence (CDD) -- IdentitySubmission and IdentityVerificationResult provide tamper-evident CDD records. o Transaction Monitoring -- TransactionMonitorAlert provides auditable evidence of the monitoring program's operation. 11.4. EU Digital Operational Resilience Act (DORA) DORA [DORA2022] requires financial institutions to maintain comprehensive ICT risk management and incident registers. RBIP's tamper-evident evidence trail, blockchain timestamping, and DOI archival satisfy DORA requirements for: o Article 9 -- Protection of ICT systems and data o Article 10 -- Detection mechanisms o Article 12 -- Backup policies o Article 17 -- ICT-related incident reporting 11.5. EU Markets in Crypto-Assets Regulation (MiCA) For institutions subject to MiCA [MiCA2023]: o PRL Module provides the reserve attestation mechanism required for Asset-Referenced Token issuers under MiCA Title III. o ReserveAttestation provides the cryptographic audit trail required for quarterly reserve audits under MiCA Article 37. 11.6. ISO/IEC 42001:2023 (AI Management Systems) For institutions using AI-based credit scoring, AML detection, or risk models: o LOC UnderwritingDecision includes decision_model_id, enabling traceability of AI model versions to decisions. o KAL TransactionMonitorAlert includes rule_id for the AI/rules model that triggered the alert. o RBIP provides the audit trail infrastructure required by ISO 42001 for AI decision auditability. ------------------------------------------------------------------------ 12. Implementation Guidance 12.1. Reference Implementation Notes A conformant RBIP Node implementation MUST provide: o Event adapter modules for common core banking systems (CBS). Reference adapters SHOULD be provided for ISO 20022 event feeds, T24 (Temenos), Flexcube (Oracle), and FIS Modern Banking Platform. o A canonical JSON serializer conforming to [RFC8785] (JCS). Implementations MUST NOT use standard JSON pretty-printers, as these produce non-canonical output. Open-source JCS libraries are available for Java, Python, Go, and Rust. o A Merkle tree implementation conforming to [RFC9162] Section 2.1 using SHA-256 leaves. o A DOI archival client capable of submitting bundles and receiving DOIs from a DataCite-member archival provider. Implementors MAY use any conforming provider's deposit API. Example: the Zenodo REST API (https://zenodo.org/api/) was used for initial reference implementation archival. o A blockchain anchoring client supporting a public, proof-of-work or proof-of-stake blockchain with publicly verifiable timestamping. The client MUST produce a proof artifact sufficient for offline verification per Section 6.4. Example: the OpenTimestamps Python client (https://github.com/opentimestamps/opentimestamps-client) was used for initial reference implementation anchoring. o A FIPS 140-2 Level 3 HSM integration layer. Reference implementations SHOULD support PKCS#11 [PKCS11] and CNG (Windows CryptoNext Generation) interfaces for HSM abstraction. o An audit log subsystem that applies RBIP evidencing recursively to its own access and operational logs. 12.2. Deployment Topologies 12.2.1. Centralized Deployment (Single RBIP Node) Suitable for smaller institutions. A single RBIP Node processes all three modules. Evidence bundles are submitted to an external DOI provider and blockchain anchoring service. 12.2.2. Federated Deployment (Module-Separated Nodes) Each RBIP module runs on a separate, isolated RBIP Node with separate HSM-backed signing keys. Module nodes submit bundles to a central Bundle Aggregator, which coordinates anchoring. Recommended for Tier 1 financial institutions. 12.2.3. Consortium Deployment Multiple institutions share an RBIP Bundle Aggregator (operated by a trusted third party such as a central bank or industry utility). Each institution runs its own RBIP Node and submits bundles to the shared aggregator, which co-anchors bundles from multiple institutions in a single blockchain transaction. This amortizes anchoring costs and provides cross-institution chronological ordering. ------------------------------------------------------------------------ 13. IANA Considerations This document requests the registration of the following media types with IANA: 13.1. application/rbip-evidence-item+json Type name: application Subtype name: rbip-evidence-item+json Required parameters: version (e.g., "rbip-01") Optional parameters: module ("PRL", "LOC", "KAL") Encoding: UTF-8 Security considerations: See Section 9 Interoperability considerations: None Published specification: This document (draft-reilly-banking-integrity-01) Author: Lawrence John Reilly Jr. 13.2. application/rbip-bundle+json Type name: application Subtype name: rbip-bundle+json Required parameters: version (e.g., "rbip-01") Encoding: UTF-8 Security considerations: See Section 9 Author: Lawrence John Reilly Jr. 13.3. application/rbip-tlpa+json Type name: application Subtype name: rbip-tlpa+json Required parameters: version (e.g., "rbip-01") Encoding: UTF-8 Security considerations: See Section 9 and 6.5 Author: Lawrence John Reilly Jr. ------------------------------------------------------------------------ 14. Acknowledgments The author thanks the financial cryptography, auditing, and regulatory technology communities for foundational work on tamper-evident ledgers, blockchain timestamping, and digital preservation that this protocol builds upon. The author acknowledges the open blockchain timestamping community for providing trust-minimized, publicly verifiable anchoring infrastructure, and the open DOI archival community for providing persistent identifier infrastructure that underpins RBIP's DOI permanence layer. This protocol specification is protected under triple-layer digital permanence per Section 1.3. The foundational whitepaper was DOI-archived on September 13, 2025 (DOI: 10.5281/zenodo.17114424), blockchain-timestamped via a public proof-of-work blockchain timestamping service, and submitted to the IETF on September 27, 2025 as draft-reilly-banking-integrity-00. This -01 revision was published March 21, 2026. ------------------------------------------------------------------------ 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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 CRL Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [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, . [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, . [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, . [RFC9162] Meeker, A., Stark, E., and E. Kasper, "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-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, . 15.2. Informative References [PKCS11] OASIS PKCS 11 TC, "PKCS #11 Cryptographic Token Interface Base Specification Version 3.0", OASIS Standard, June 2020, . [I-D.draft-reilly-rem-protocol] Reilly, L.J., "Reilly EternaMark (REM) Protocol: Dual-Layer Digital Permanence via DOI Archival and Blockchain Timestamping", Internet-Draft, draft-reilly-rem-protocol (work in progress), September 2025, . [I-D.draft-reilly-cts-00] Reilly, L.J., "Cognitive Trust Stack (CTS): AI Behavioral Provenance Framework", Internet-Draft, draft-reilly-cts-00 (work in progress), 2026, . [RBIP-Whitepaper] Reilly, L.J., "Reilly Banking Integrity Protocol (RBIP): Ensuring Permanent and Regulator-Verifiable Audit Trails", September 13, 2025, DOI: 10.5281/zenodo.17114424, . NOTE: Archived at Zenodo as the initial reference implementation of triple-layer permanence for this specification. Implementations are not required to use Zenodo; any DataCite-member archival provider is conforming. [OTS] Todd, P. et al., "OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin", . NOTE: Used as the initial blockchain timestamping implementation for this specification. Implementations are not required to use OpenTimestamps or Bitcoin; any public blockchain anchoring service satisfying Section 6.4 is conforming. [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, . [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 Special Publication 800-38D, November 2007, . [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. ------------------------------------------------------------------------ Author's Address Lawrence John Reilly Jr. Independent Researcher Email: lreilly250@gmail.com IETF Datatracker: https://datatracker.ietf.org/person/lreilly250@gmail.com This document is protected under triple-layer digital permanence per Section 1.3: * DOI: 10.5281/zenodo.17114424 (archived 2025-09-13) * Blockchain timestamp via public proof-of-work network (2025-09-13) * IETF submission: draft-reilly-banking-integrity-00 (2025-09-27) * This version (-01): 2026-03-21