Reilly Banking Integrity Protocol (RBIP)
draft-reilly-banking-integrity-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Lawrence John Reilly Jr. | ||
| Last updated | 2026-03-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-reilly-banking-integrity-01
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": "<UUID v4>",
"schema_version": "rbip-01",
"institution_id": "<LEI or BIC>",
"modules_included": ["PRL", "LOC", "KAL"],
"interval_start": "<ISO 8601 UTC datetime>",
"interval_end": "<ISO 8601 UTC datetime>",
"item_count": <integer>,
"merkle_root": "sha256:<64 hex chars>",
"merkle_tree": [
{ "index": 0, "evidence_id": "<id>", "digest": "sha256:<...>" },
...
],
"prev_bundle_digest": "sha256:<64 hex chars>",
"doi": "<DOI URI or null if not yet archived>",
"blockchain_anchor": {
"chain": "<chain identifier, e.g., bitcoin, ethereum>",
"tx_id": "<transaction hash>",
"block_height": <integer>,
"block_timestamp": "<ISO 8601 UTC datetime>",
"proof": "<Base64-encoded timestamping proof blob>"
},
"bundle_digest": "sha256:<64 hex chars>",
"bundle_signature": "<JWS Compact Serialization over bundle_digest>"
}
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": "<id>",
"bundle_id": "<id>",
"leaf_digest": "sha256:<...>",
"proof_path": [
{ "direction": "left", "digest": "sha256:<...>" },
{ "direction": "right", "digest": "sha256:<...>" },
...
],
"merkle_root": "sha256:<...>",
"doi": "10.5281/zenodo.<record>",
"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 "<amount> <ISO 4217 currency code>" (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": "<ISO 8601 date>",
"reserve_assets": [
{
"asset_class": "cash" | "hqla_l1" | "hqla_l2a" | "hqla_l2b" | "other",
"asset_id": "<internal asset reference or ISIN>",
"market_value": "<amount> <CCY>",
"haircut_pct": "<decimal 0.00-100.00>",
"post_haircut_value": "<amount> <CCY>"
}
],
"total_hqla": "<amount> <CCY>",
"lcr_ratio": "<decimal>",
"nsfr_ratio": "<decimal>",
"tier1_capital_ratio": "<decimal>",
"attestation_officer": "<name and LEI or employee ID>",
"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": "<identifier>",
"horizon_days": <integer>,
"baseline_lcr": "<decimal>",
"stressed_lcr": "<decimal>",
"survival_days": <integer>,
"assumptions": [
{ "parameter": "<string>", "value": "<string>", "basis": "<string>" }
],
"model_version": "<semver string>",
"run_timestamp": "<ISO 8601 UTC datetime>"
}
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": "<evidence_id of the ReserveSnapshot>",
"attestor_name": "<full legal name>",
"attestor_role": "CFO" | "CRO" | "external_auditor" | "regulator",
"attestor_institution": "<LEI>",
"attestation_scope": "<free text, e.g., Basel III LCR compliance, Q4 2025>",
"pgp_signature": "<armored PGP signature over the attested snapshot digest>",
"certificate_ref": "<X.509 certificate serial number or thumbprint>"
}
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": "<internal loan application ID>",
"application_date": "<ISO 8601 date>",
"loan_type": "residential_mortgage" | "commercial_real_estate" | "auto" | "personal" | "sme" | "syndicated" | "other",
"requested_amount": "<amount> <CCY>",
"requested_term_months": <integer>,
"applicant_hash": "sha256:<hash of anonymized applicant identifier>",
"origination_channel":"branch" | "digital" | "broker" | "wholesale",
"jurisdiction": "<ISO 3166-1 alpha-2 country code>"
}
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": "<ref to LoanApplication>",
"decision": "approved" | "declined" | "referred" | "conditionally_approved",
"decision_date": "<ISO 8601 date>",
"decision_rationale_hash": "sha256:<hash of rationale document>",
"approved_amount": "<amount> <CCY>",
"approved_rate": "<decimal as percentage>",
"approved_term_months": <integer>,
"conditions": [
{ "condition_id": "<id>", "description_hash": "sha256:<...>", "deadline": "<date>" }
],
"decision_model_id": "<model version reference>",
"underwriter_hash": "sha256:<hash of underwriter ID>"
}
5.5.3. CollateralBinding
data_fields:
{
"loan_id": "<approved loan ID>",
"collateral_id": "<unique collateral item ID>",
"collateral_type": "residential_property" | "commercial_property" | "securities" | "vehicle" | "equipment" | "cash_deposit" | "guarantee" | "other",
"collateral_ref": "<ISIN, title number, VIN, or other external reference>",
"valuation": "<amount> <CCY>",
"valuation_method": "automated_valuation" | "desktop_appraisal" | "full_appraisal" | "market_price",
"valuation_date": "<ISO 8601 date>",
"ltv_ratio": "<decimal>",
"lien_position": "first" | "second" | "subordinate",
"binding_date": "<ISO 8601 date>",
"perfection_ref": "<UCC filing number or land registry reference>"
}
5.5.4. CollateralRevaluation
data_fields:
{
"collateral_id": "<ref to CollateralBinding>",
"prior_valuation": "<amount> <CCY>",
"new_valuation": "<amount> <CCY>",
"revaluation_date": "<ISO 8601 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": "<decimal>",
"margin_call_triggered": <boolean>
}
5.5.5. LoanDisbursement
data_fields:
{
"loan_id": "<id>",
"disbursement_id": "<unique disbursement ID>",
"disbursement_date": "<ISO 8601 UTC datetime>",
"amount": "<amount> <CCY>",
"disbursement_method":"wire_transfer" | "ach" | "check" | "internal_credit",
"destination_hash": "sha256:<hash of destination account reference>",
"conditions_satisfied": [{ "condition_id": "<id>", "satisfied_date": "<date>" }]
}
5.5.6. PaymentReceipt
data_fields:
{
"loan_id": "<id>",
"payment_id": "<unique payment ID>",
"payment_date": "<ISO 8601 UTC datetime>",
"amount": "<amount> <CCY>",
"principal_component":"<amount> <CCY>",
"interest_component": "<amount> <CCY>",
"fees_component": "<amount> <CCY>",
"days_past_due": <integer, 0 if current>,
"payment_channel": "ach" | "wire" | "internal" | "cash" | "check"
}
5.5.7. DefaultEvent / RecoveryEvent
data_fields:
{
"loan_id": "<id>",
"event_subtype": "default_declaration" | "recovery_partial" | "recovery_full" | "charge_off" | "workout_agreement",
"event_date": "<ISO 8601 date>",
"days_past_due_at_default": <integer>,
"outstanding_balance":"<amount> <CCY>",
"recovery_amount": "<amount> <CCY>",
"lgd_estimate": "<decimal, loss given default, 0.00-1.00>",
"resolution_timeline_days": <integer>
}
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": "<unique ID>",
"submission_date": "<ISO 8601 UTC datetime>",
"customer_type": "individual" | "entity" | "correspondent_bank" | "pep",
"identity_doc_type": "passport" | "national_id" | "drivers_license" | "entity_registration" | "other",
"doc_hash": "sha256:<hash of identity document image or data>",
"liveness_check_result": "pass" | "fail" | "not_required",
"submission_channel": "branch" | "digital_onboarding" | "api_partner"
}
5.6.2. IdentityVerificationResult
data_fields:
{
"submission_id": "<ref to IdentitySubmission>",
"verification_date": "<ISO 8601 UTC datetime>",
"result": "verified" | "failed" | "referred" | "escalated",
"verification_method":"automated_ocr_biometric" | "manual_review" | "third_party_bureau" | "video_interview",
"risk_score": <integer 0-1000>,
"risk_tier": "low" | "medium" | "high" | "prohibited",
"sanctions_checked": <boolean>,
"pep_checked": <boolean>,
"adverse_media_checked": <boolean>,
"next_review_date": "<ISO 8601 date>"
}
5.6.3. TransactionMonitorAlert
data_fields:
{
"alert_id": "<unique alert ID>",
"alert_generated_at": "<ISO 8601 UTC datetime>",
"alert_type": "structuring" | "layering" | "unusual_velocity" | "sanctions_match" | "pep_activity" | "high_risk_jurisdiction" | "other",
"rule_id": "<AML rule or model ID that triggered>",
"customer_hash": "sha256:<hash of customer ID>",
"transaction_count": <integer>,
"aggregate_amount": "<amount> <CCY>",
"risk_score": <integer 0-1000>,
"auto_disposition": "escalated_to_analyst" | "auto_cleared" | "pending"
}
5.6.4. SARSubmission
data_fields:
{
"sar_reference_hash": "sha256:<hash of SAR filing reference number>",
"submission_date": "<ISO 8601 UTC datetime>",
"jurisdiction": "<ISO 3166-1 alpha-2>",
"fiu_agency": "FinCEN" | "NCA" | "FINTRAC" | "AUSTRAC" | "other",
"activity_type": "money_laundering" | "terrorist_financing" | "fraud" | "structuring" | "other",
"subject_count": <integer>,
"reporting_period_start": "<ISO 8601 date>",
"reporting_period_end": "<ISO 8601 date>",
"filing_status": "initial" | "corrective" | "continuing"
}
5.6.5. CaseEscalation
data_fields:
{
"case_id": "<unique case ID>",
"escalation_date": "<ISO 8601 UTC datetime>",
"from_tier": "l1_analyst" | "l2_investigator" | "l3_senior",
"to_tier": "l2_investigator" | "l3_senior" | "compliance_officer" | "law_enforcement",
"escalation_reason": "<free text, hashed if sensitive>",
"linked_alert_ids": ["<alert_id>", ...],
"linked_sar_hashes": ["sha256:<...>", ...]
}
5.6.6. CaseClosure
data_fields:
{
"case_id": "<ref to CaseEscalation>",
"closure_date": "<ISO 8601 UTC datetime>",
"closure_outcome": "no_action" | "sar_filed" | "account_closed" | "law_enforcement_referral" | "regulatory_disclosure",
"investigation_duration_days": <integer>,
"disposition_hash": "sha256:<hash of case disposition document>"
}
------------------------------------------------------------------------
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 - <institution_id> -
<interval_start> to <interval_end>"
* creator: <institution legal name and LEI>
* publicationYear: <YYYY>
* resourceType: "Dataset"
* description: "RBIP-01 evidence bundle: <modules> events,
merkle_root: <value>"
* identifier: <DOI assigned by provider>
* relatedIdentifier: <prior bundle DOI>
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/<doi>) 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: <chain identifier string, e.g., "bitcoin", "ethereum">
* tx_id: <transaction hash>
* block_height: <block number>
* block_timestamp: <block header timestamp, ISO 8601 UTC>
* proof: <Base64-encoded timestamping proof blob>
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": "<id>",
"bundle_digest": "sha256:<...>",
"layer_1_doi": {
"doi": "<DOI assigned by archival provider>",
"doi_url": "https://doi.org/<doi>",
"archived_at": "<ISO 8601 UTC datetime>",
"provider": "<name of DOI archival provider>"
},
"layer_2_blockchain": {
"chain": "<chain identifier, e.g., bitcoin, ethereum>",
"tx_id": "<tx hash>",
"block_height": <integer>,
"block_timestamp": "<ISO 8601 UTC datetime>",
"proof_sha256": "sha256:<hash of timestamping proof blob>",
"confirmations_at_finality": <integer>
},
"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:<hash of canonical TLPA object with tlpa_digest=''>",
"tlpa_signature": "<JWS over tlpa_digest>"
}
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/<doi>. 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://<rbip-node.institution.internal>/v1/
7.1.1. Submit Evidence Event
POST /events
Request Body:
{
"module": "PRL" | "LOC" | "KAL",
"event_type": "<event type string>",
"occurred_at": "<ISO 8601 UTC datetime>",
"data_fields": { ... },
"metadata": { ... }
}
Response 202 Accepted:
{
"evidence_id": "<module-prefixed UUID>",
"accepted_at": "<ISO 8601 UTC datetime>",
"bundle_queue_position": <integer>
}
Response 400 Bad Request:
{
"error": "INVALID_EVENT_TYPE" | "MISSING_REQUIRED_FIELD" | "SCHEMA_VIOLATION",
"detail": "<human-readable description>"
}
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=<evidence_id>&limit=<int>
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=<module>&start=<datetime>&end=<datetime>&page=<int>
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://<rbip-node.institution.external>/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": "<id>",
"bundle_id": "<id>",
"leaf_digest": "sha256:<...>",
"proof_path": [ { "direction": "left"|"right", "digest": "sha256:<...>" }, ... ],
"merkle_root": "sha256:<...>",
"doi": "<DOI URI>",
"blockchain_anchor": { ... },
"tlpa": { ... }
}
7.2.3. Verify Chain Integrity
POST /verify/chain
Request Body:
{
"module": "PRL" | "LOC" | "KAL",
"from_date": "<ISO 8601 date>",
"to_date": "<ISO 8601 date>"
}
Response:
{
"status": "VERIFIED" | "CHAIN_GAP_DETECTED" | "DIGEST_MISMATCH" | "ANCHOR_INVALID",
"bundle_count": <integer>,
"item_count": <integer>,
"first_bundle_id": "<id>",
"last_bundle_id": "<id>",
"anomalies": [ { "type": "<string>", "bundle_id": "<id>", "detail": "<string>" } ]
}
7.2.4. Verify Blockchain Anchor
POST /verify/anchor
Request Body:
{
"bundle_id": "<id>"
}
Response:
{
"bundle_id": "<id>",
"anchor_valid": <boolean>,
"chain": "<chain identifier>",
"tx_id": "<hash>",
"block_height": <integer>,
"block_timestamp": "<ISO 8601 UTC datetime>",
"confirmations": <integer>,
"proof_verification": "VERIFIED" | "PENDING" | "FAILED",
"doi_resolvable": <boolean>
}
7.2.5. Selective Disclosure Request
POST /disclose
Request Body:
{
"bundle_id": "<id>",
"evidence_ids": ["<id>", ...],
"fields": ["<field_name>", ...],
"purpose": "<regulatory authority and regulatory basis for disclosure>"
}
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=<datetime>&to=<datetime>
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://<institution.example.com>/rbip/public/v1/
7.3.1. Get Anchor Summary
GET /anchors?module=<module>&period=<YYYY-MM>
Returns:
{
"institution_id": "<LEI or BIC>",
"module": "PRL" | "LOC" | "KAL",
"period": "<YYYY-MM>",
"bundle_count": <integer>,
"latest_anchor": {
"bundle_id": "<id>",
"block_height": <integer>,
"block_timestamp": "<ISO 8601 UTC datetime>",
"doi": "<DOI URI>",
"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. <lreilly250@gmail.com>
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. <lreilly250@gmail.com>
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. <lreilly250@gmail.com>
------------------------------------------------------------------------
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,
<https://www.rfc-editor.org/info/rfc2119>.
[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, <https://www.rfc-editor.org/info/rfc3161>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339,
July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[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,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515,
May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Token (JWT)", RFC 7519, DOI 10.17487/RFC7519,
May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON)
Data Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS)
Protocol Version 1.3", RFC 8446,
DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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,
<https://www.rfc-editor.org/info/rfc8705>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9162] Meeker, A., Stark, E., and E. Kasper, "Certificate
Transparency Version 2.0", RFC 9162,
DOI 10.17487/RFC9162, December 2021,
<https://www.rfc-editor.org/info/rfc9162>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally
Unique IDentifiers (UUIDs)", RFC 9562,
DOI 10.17487/RFC9562, May 2024,
<https://www.rfc-editor.org/info/rfc9562>.
[FIPS-180-4] National Institute of Standards and Technology,
"Secure Hash Standard (SHS)", FIPS PUB 180-4,
August 2015,
<https://csrc.nist.gov/publications/detail/fips/180/4/final>.
[FIPS-202] National Institute of Standards and Technology,
"SHA-3 Standard: Permutation-Based Hash and Extendable-
Output Functions", FIPS PUB 202, August 2015,
<https://csrc.nist.gov/publications/detail/fips/202/final>.
15.2. Informative References
[PKCS11] OASIS PKCS 11 TC, "PKCS #11 Cryptographic Token
Interface Base Specification Version 3.0",
OASIS Standard, June 2020,
<https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/pkcs11-base-v3.0.html>.
[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,
<https://datatracker.ietf.org/doc/draft-reilly-rem-protocol/>.
[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,
<https://datatracker.ietf.org/doc/draft-reilly-cts/>.
[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,
<https://zenodo.org/records/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",
<https://opentimestamps.org/>.
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,
<https://schema.datacite.org/meta/kernel-4.5/>.
[FIPS-204] National Institute of Standards and Technology,
"Module-Lattice-Based Digital Signature Standard
(ML-DSA)", FIPS PUB 204, August 2024,
<https://csrc.nist.gov/pubs/fips/204/final>.
[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,
<https://csrc.nist.gov/publications/detail/sp/800/38d/final>.
[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