SR 26-2 and the evidentiary record

Walk into any bank’s compliance function and you will find three teams keeping three sets of books. Model risk maintains documentation for supervisory expectations like SR 26-2. Fair-lending tracks decisions against ECOA and Regulation B. The UDAAP function watches for unfair, deceptive, or abusive patterns. Three mandates, three audiences, three archives. A8 Core™’s thesis is that, at the level of the underlying facts, they are one record.

The same four facts

Strip each obligation down and the examiner is asking variations of the same question: what was decided, when, on what inputs, and by whom? A fair-lending review wants to know an adverse decision was not driven by a prohibited basis. A model-risk review wants to know which model version produced an output and on what data. A UDAAP review wants the pattern of outcomes across customers. None of those can be answered without a faithful, timestamped, attributable record of decisions and their inputs. That record is the same record.

You do not have a model-risk record and a fair-lending record. You have one evidentiary record, read three ways.

What “evidentiary” requires

Calling something a log is easy. Calling it evidentiary sets a higher bar, because evidence has to survive scrutiny. A8 Core™ designs the record to meet that bar:

• Immutable and append-only. Corrections are new entries, never silent edits. The history of a decision is itself part of the evidence.
• Attributable. Every entry ties to an actor and, where an autonomous agent acted, to both the agent and the human it acted for.
• Timestamped and ordered. When matters as much as what.
• Keyed to a request. The RequestId on every API response threads your systems to ours.

Because the record is produced as a byproduct of the operation rather than reconstructed afterward, there is no gap between what happened and what was logged. The directive and its evidence are written together.

A note on scope, stated plainly

Supervisory guidance is specific, and it is worth being precise rather than expansive. SR 26-2 addresses model risk, and its own footnotes are careful about what it does and does not reach — notably, it does not extend to generative and agentic AI. A8 Core™ does not paper over that boundary. What the platform does is capture the operational facts regardless of how a decision was produced: when an agent acts, the dual-principal authorization model records both the agent and the human, so the evidentiary trail exists whether or not a given technique sits inside any one framework’s scope.

What builders inherit

The reason to build this into the core, rather than leave it to each integrator, is that a record assembled after the fact is a record an examiner can question. By making it a platform feature, every directive any provider issues lands in the same shape: inputs, decision, outcome, actor, time, request. You do not build the record. You inherit it.

The operational payoff

• An exam request becomes a query, not a forensic reconstruction.
• Three compliance functions read one source instead of reconciling three.
• New products arrive already producing audit-ready evidence on day one.

Compliance as infrastructure

The industry tends to treat compliance as a cost center bolted onto the side of a product. A8 Core™ treats it as infrastructure: a property of the core that every account type and every directive gets for free. That is the difference between a system that can be made compliant and one that produces the evidence of compliance as it runs.

When the worst day comes — the dispute, the exam, the lookback — the institution that built the record once, into the platform, is the one that can simply show its work.