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