When four AI agents collaborate on a lending decision, who is accountable? Each agent becomes a milestone. The pipeline becomes a phase. The loan becomes a structure root. One hash proves the entire chain.
v8.1 Preview • Hierarchical Milestone Merkle Trees ship in SWT3 v8.1 (November 2026). SDK parity across Python and TypeScript. API endpoints go live on release.
Who this is for: SR 26-2 model risk examiners, fair lending compliance officers, AI/ML platform engineers building multi-agent pipelines, C3PAO assessors evaluating AI chain-of-custody evidence, and developers integrating phased witnessing into regulated inference workflows.
A single AI model making a single prediction has a clear accountability boundary. The model received input X, produced output Y, and the evidence chain is one attestation deep.
Multi-agent workflows destroy that simplicity. When four agents collaborate on a lending decision -- one extracts documents, one scores credit risk, one checks regulatory compliance, one synthesizes the final approval or denial -- the accountability question becomes: which agent caused the outcome?
If a loan is denied and the applicant files an ECOA adverse action dispute, the lender must reconstruct the entire chain. Which agent saw the applicant's data? What did the credit scoring model produce? Did the compliance agent flag a fair lending concern, or did it miss one? Did the decision agent weigh all inputs correctly, or did it override one?
Today, the answer lives in scattered log files across four services. Each agent logs its own events in its own format. Correlating those logs into a single, tamper-evident chain for a specific loan application requires forensic engineering. Under examination pressure, that reconstruction is expensive, slow, and fragile.
The gap is not that the agents lack logging. The gap is that no single cryptographic structure links all four agents' evidence to one decision, proving that every step happened in sequence and that no step was skipped or altered after the fact.
Phased witnessing closes that gap. Each agent becomes a milestone. The loan decision pipeline becomes a phase. The loan application becomes a structure. One root hash represents the complete, tamper-evident record of every agent's contribution to that specific lending decision.
Consider a mid-size lender that processes consumer loan applications using four specialized AI agents:
Reads application documents (pay stubs, tax returns, bank statements). Extracts structured data: income, employment history, existing liabilities. Records evidence under AI-TOOL.1 (tool call witnessing) and NHI-AGENT.1 (non-human identity).
Runs a credit risk model on the extracted data. Outputs a risk score, probability of default, and contributing factors. Records evidence under AI-CHAIN.1 (inference chain witnessing) and AI-EXPL.1 (explainability).
Evaluates the application and risk score against ECOA fair lending rules, FCRA permissible purpose requirements, and the lender's internal fair lending policy. Records evidence under AI-FAIR.1 (fairness and bias evaluation) and NHI-SCOPE.1 (scope boundaries).
Combines all inputs from the previous three agents. Produces a final approval or denial with a human-readable explanation of the factors. Records evidence under AI-HITL.1 (human-in-the-loop) and AI-EXPL.1 (explainability). For denials, generates the adverse action reason codes required by ECOA.
The four agents execute in sequence. Document Extraction feeds Credit Scoring. Credit Scoring and the raw application feed Compliance Check. All three feed Decision Synthesis. The pipeline runs in under two seconds. The evidence must survive for seven years.
Each agent maps to a milestone in the hierarchical Merkle tree. The agent's attestations (tool calls, inference results, compliance checks) are leaves within that milestone. The pipeline is a phase. The loan application is a structure.
Attestation Fingerprints (individual witness records)
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
|AI-TOOL.1 | |NHI-AGT.1 | |AI-CHAIN.1| |AI-EXPL.1 | |AI-FAIR.1 | |AI-HITL.1 |
|doc extract| |agent id | |credit run| |score expl| |fair lend | |decision |
+----+-----+ +----+-----+ +----+-----+ +----+-----+ +----+-----+ +----+-----+
| | | | | |
+------+------+ +------+------+ | |
v v v v
+-------------------+ +-------------------+ +------------------+ +-----------------+
| MS-doc-extraction | | MS-credit-scoring | | MS-compliance | | MS-decision |
| Milestone Root | | Milestone Root | | Milestone Root | | Milestone Root |
+--------+----------+ +--------+----------+ +--------+---------+ +--------+--------+
| | | |
+----------+-----------+-----------+-----------+ |
| |
+-------------------------+-------------------------------+
v
+------------------------+
| PH-underwriting |
| Phase Root |
| "Loan Pipeline" |
+-----------+------------+
|
v
+------------------------+
| ST-loan-2026-11-0042 |
| Structure Root |
| "Loan Application" |
+------------------------+Four agents, four milestones, one phase, one structure root. Every attestation from every agent rolls up to a single hash representing the complete lending decision.
The structure root changes every time any agent records a new attestation. If the compliance agent re-runs after a policy update, the milestone root changes, the phase root changes, and the structure root changes. The entire chain is tamper-evident from any single leaf to the top.
Assessor Note
Agent identity verification: each NHI-AGENT.1 anchor must carry a unique agent_id. If all four agents produce anchors with the same agent_id hash, they are indistinguishable in the evidence chain -- a single point of failure for accountability. During examination, verify that each milestone contains at least one NHI-AGENT.1 leaf with a distinct agent_id. Four agents, four identities, no exceptions.
Each agent in the pipeline can run as an MCP (Model Context Protocol) server. The SWT3 MCP server (@tenova/swt3-mcp) exposes witnessing tools that agents call during execution. Two tools are relevant for multi-agent pipelines:
witness_inference -- records the agent's inference result with procedure, factors, and verdict. Accepts optional milestone_id, phase_id, and structure_id fields that place the attestation in the correct position in the hierarchy.witness_tool_call -- records external tool invocations (API calls, database queries, document parsing) that the agent performed during its work.When an MCP-enabled agent calls witness_inference with a milestone_id, the attestation is automatically added as a leaf in that milestone's Merkle tree. No additional wiring is needed. The agent does its work; the MCP server records the evidence in the right place.
| Agent | MCP Tool | Milestone ID | Procedures |
|---|---|---|---|
| Document Extraction | witness_tool_call, witness_inference | MS-doc-extraction | AI-TOOL.1, NHI-AGENT.1 |
| Credit Scoring | witness_inference | MS-credit-scoring | AI-CHAIN.1, AI-EXPL.1 |
| Compliance Check | witness_inference | MS-compliance | AI-FAIR.1, NHI-SCOPE.1 |
| Decision Synthesis | witness_inference | MS-decision | AI-HITL.1, AI-EXPL.1 |
Each agent's MCP server configuration includes its milestone_id, phase_id, and structure_id. The orchestrator creates the structure and phases once per loan application, then each agent records into its designated milestone as it executes.
The complete Python implementation for a four-agent loan underwriting pipeline. This example creates the structure, defines milestones for each agent, records attestations as each agent completes its work, and checks the compliance gate before the decision agent runs.
from swt3_ai import Witness
from swt3_ai.milestone_merkle import MilestoneAccumulator, verify_multi_tier_proof
# --- Step 1: Create the structure for this loan application ---
loan_id = "2026-11-0042"
acc = MilestoneAccumulator(structure_id=f"ST-loan-{loan_id}")
# One phase: the underwriting pipeline
acc.add_phase("PH-underwriting", "Loan Underwriting Pipeline", sequence=0)
# Four milestones -- one per agent
acc.add_milestone(
"MS-doc-extraction", "PH-underwriting", "Document Extraction",
required_procedures=["AI-TOOL.1", "NHI-AGENT.1"],
min_attestation_count=1
)
acc.add_milestone(
"MS-credit-scoring", "PH-underwriting", "Credit Scoring",
required_procedures=["AI-CHAIN.1", "AI-EXPL.1"],
min_attestation_count=1
)
acc.add_milestone(
"MS-compliance", "PH-underwriting", "Compliance Check",
required_procedures=["AI-FAIR.1", "NHI-SCOPE.1"],
min_attestation_count=1
)
acc.add_milestone(
"MS-decision", "PH-underwriting", "Decision Synthesis",
required_procedures=["AI-HITL.1", "AI-EXPL.1"],
min_attestation_count=1
)
# --- Step 2: Each agent witnesses its work ---
# Agent 1: Document Extraction
doc_witness = Witness(
endpoint="https://sovereign.tenova.io/api/v1/witness",
api_key="axm_live_...",
tenant_id="LENDER_ENCLAVE",
agent_id="doc-extraction-agent-v2.1",
flush_interval=5
)
# Record the extraction tool call
doc_result = doc_witness.witness_inference(
model_id="extraction-llm-v2",
procedure="AI-TOOL.1",
input_data="application-docs-sha256:9f3a...",
output_data="structured-data-sha256:2c7b...",
factor_a="documents_parsed:12",
factor_b="fields_extracted:47",
factor_c="confidence:0.97",
milestone_id="MS-doc-extraction",
phase_id="PH-underwriting",
structure_id=f"ST-loan-{loan_id}"
)
acc.add_leaf("MS-doc-extraction", doc_result["fingerprint"],
"AI-TOOL.1", verdict="PASS")
# Record agent identity
id_result = doc_witness.witness_inference(
model_id="extraction-llm-v2",
procedure="NHI-AGENT.1",
input_data="agent-manifest-sha256:e1d4...",
output_data="identity-bound",
factor_a="agent_version:2.1.0",
factor_b="signing_key_hash:7a9c...",
factor_c="scope:document_extraction_only",
milestone_id="MS-doc-extraction",
phase_id="PH-underwriting",
structure_id=f"ST-loan-{loan_id}"
)
acc.add_leaf("MS-doc-extraction", id_result["fingerprint"],
"NHI-AGENT.1", verdict="PASS")
# Agent 2: Credit Scoring
credit_witness = Witness(
endpoint="https://sovereign.tenova.io/api/v1/witness",
api_key="axm_live_...",
tenant_id="LENDER_ENCLAVE",
agent_id="credit-scoring-agent-v3.4",
flush_interval=5
)
credit_result = credit_witness.witness_inference(
model_id="credit-risk-model-v3.4",
procedure="AI-CHAIN.1",
input_data="structured-data-sha256:2c7b...",
output_data="risk-score:0.23:pd:0.041",
factor_a="model_version:3.4.1",
factor_b="feature_count:128",
factor_c="score:0.23",
milestone_id="MS-credit-scoring",
phase_id="PH-underwriting",
structure_id=f"ST-loan-{loan_id}"
)
acc.add_leaf("MS-credit-scoring", credit_result["fingerprint"],
"AI-CHAIN.1", verdict="PASS")
expl_result = credit_witness.witness_inference(
model_id="credit-risk-model-v3.4",
procedure="AI-EXPL.1",
input_data="risk-score:0.23",
output_data="top_factors:income_ratio,credit_history,dti",
factor_a="explanation_method:SHAP",
factor_b="top_features:3",
factor_c="explanation_coverage:0.89",
milestone_id="MS-credit-scoring",
phase_id="PH-underwriting",
structure_id=f"ST-loan-{loan_id}"
)
acc.add_leaf("MS-credit-scoring", expl_result["fingerprint"],
"AI-EXPL.1", verdict="PASS")
# Agent 3: Compliance Check
compliance_witness = Witness(
endpoint="https://sovereign.tenova.io/api/v1/witness",
api_key="axm_live_...",
tenant_id="LENDER_ENCLAVE",
agent_id="compliance-agent-v1.8",
flush_interval=5
)
fair_result = compliance_witness.witness_inference(
model_id="fair-lending-rules-v1.8",
procedure="AI-FAIR.1",
input_data="application-profile-sha256:4b1e...",
output_data="ecoa_compliant:true:disparate_impact:none_detected",
factor_a="protected_classes_checked:7",
factor_b="disparate_impact_ratio:0.92",
factor_c="fcra_purpose:legitimate_credit_decision",
milestone_id="MS-compliance",
phase_id="PH-underwriting",
structure_id=f"ST-loan-{loan_id}"
)
acc.add_leaf("MS-compliance", fair_result["fingerprint"],
"AI-FAIR.1", verdict="PASS")
scope_result = compliance_witness.witness_inference(
model_id="fair-lending-rules-v1.8",
procedure="NHI-SCOPE.1",
input_data="agent-scope-definition",
output_data="scope:ecoa_fcra_fair_lending_only",
factor_a="data_accessed:application,credit_report",
factor_b="data_not_accessed:hr_records,social_media",
factor_c="scope_boundary:lending_compliance",
milestone_id="MS-compliance",
phase_id="PH-underwriting",
structure_id=f"ST-loan-{loan_id}"
)
acc.add_leaf("MS-compliance", scope_result["fingerprint"],
"NHI-SCOPE.1", verdict="PASS")
# --- Step 3: Flush all agents, then check the compliance gate ---
# Witness instances buffer attestations and transmit on flush_interval
# or explicit flush. Before checking the gate, ensure all attestations
# from Agents 1-3 have been transmitted to the ledger.
doc_witness.flush()
credit_witness.flush()
compliance_witness.flush()
gate = acc.check_gate("PH-underwriting")
# At this point, MS-decision has no leaves yet. The gate evaluates ALL
# milestones in the phase -- MS-decision will appear in failing_milestones
# because its required procedures (AI-HITL.1, AI-EXPL.1) have no attestations.
# We intentionally check only the upstream milestones here:
upstream_ok = all(
m not in gate.get("failing_milestones", [])
for m in ["MS-doc-extraction", "MS-credit-scoring", "MS-compliance"]
)
if not upstream_ok:
raise RuntimeError("Pre-decision compliance gate failed -- cannot proceed")
# MS-decision is expected to be failing at this point -- Agent 4 has not run yet
# Agent 4: Decision Synthesis (runs only after upstream agents pass)
decision_witness = Witness(
endpoint="https://sovereign.tenova.io/api/v1/witness",
api_key="axm_live_...",
tenant_id="LENDER_ENCLAVE",
agent_id="decision-agent-v2.0",
flush_interval=5
)
decision_result = decision_witness.witness_inference(
model_id="decision-synthesis-v2.0",
procedure="AI-HITL.1",
input_data="all-agent-outputs-sha256:d83f...",
output_data="decision:approved:rate:6.25",
factor_a="human_reviewer:loan_officer_7291",
factor_b="review_type:post_decision_audit_sample",
factor_c="override:none",
milestone_id="MS-decision",
phase_id="PH-underwriting",
structure_id=f"ST-loan-{loan_id}"
)
acc.add_leaf("MS-decision", decision_result["fingerprint"],
"AI-HITL.1", verdict="PASS")
final_expl = decision_witness.witness_inference(
model_id="decision-synthesis-v2.0",
procedure="AI-EXPL.1",
input_data="decision:approved",
output_data="reason:income_sufficient:credit_good:compliant",
factor_a="factors_considered:risk_score,dti,fair_lending",
factor_b="adverse_action_codes:none",
factor_c="explanation_format:ecoa_compliant",
milestone_id="MS-decision",
phase_id="PH-underwriting",
structure_id=f"ST-loan-{loan_id}"
)
acc.add_leaf("MS-decision", final_expl["fingerprint"],
"AI-EXPL.1", verdict="PASS")
# --- Step 4: Flush decision agent, then final gate check ---
decision_witness.flush()
final_gate = acc.check_gate("PH-underwriting")
print(f"Gate passed: {final_gate['passed']}") # True
print(f"Structure root: {acc.structure_root}") # Single hash
print(f"Failing milestones: {final_gate.get('failing_milestones', [])}") # []
import { MilestoneAccumulator, verifyMultiTierProof } from "@tenova/swt3-ai/milestone-merkle";
const acc = new MilestoneAccumulator("ST-loan-2026-11-0042");
acc.addPhase("PH-underwriting", "Loan Underwriting Pipeline", 0);
acc.addMilestone("MS-doc-extraction", "PH-underwriting", "Document Extraction",
["AI-TOOL.1", "NHI-AGENT.1"]);
acc.addMilestone("MS-credit-scoring", "PH-underwriting", "Credit Scoring",
["AI-CHAIN.1", "AI-EXPL.1"]);
acc.addMilestone("MS-compliance", "PH-underwriting", "Compliance Check",
["AI-FAIR.1", "NHI-SCOPE.1"]);
acc.addMilestone("MS-decision", "PH-underwriting", "Decision Synthesis",
["AI-HITL.1", "AI-EXPL.1"]);
// Each agent adds leaves as it executes...
acc.addLeaf("MS-doc-extraction", docFingerprint, "AI-TOOL.1", "PASS");
acc.addLeaf("MS-doc-extraction", idFingerprint, "NHI-AGENT.1", "PASS");
acc.addLeaf("MS-credit-scoring", creditFingerprint, "AI-CHAIN.1", "PASS");
acc.addLeaf("MS-credit-scoring", explFingerprint, "AI-EXPL.1", "PASS");
acc.addLeaf("MS-compliance", fairFingerprint, "AI-FAIR.1", "PASS");
acc.addLeaf("MS-compliance", scopeFingerprint, "NHI-SCOPE.1", "PASS");
// Gate check before decision agent
const preGate = acc.checkGate("PH-underwriting");
// Decision agent records...
acc.addLeaf("MS-decision", hitlFingerprint, "AI-HITL.1", "PASS");
acc.addLeaf("MS-decision", finalExplFingerprint, "AI-EXPL.1", "PASS");
const finalGate = acc.checkGate("PH-underwriting");
console.log(finalGate.passed); // true
console.log(acc.structureRoot); // Single hash for entire loan decision
The most critical gate in the pipeline is the one between the Compliance Check agent and the Decision Synthesis agent. If the compliance agent determines that the application has a fair lending issue or an FCRA violation, the decision agent must not proceed to synthesize an approval.
This is where gatekeeper mode becomes essential. When enabled by the deployer, the phase gate blocks downstream processing until all upstream milestones have terminal PASS verdicts for every required procedure.
Consider a loan application where the compliance agent detects that the credit report was pulled without a permissible purpose under FCRA Section 604:
# Compliance agent records a FAIL for fair lending
fair_result = compliance_witness.witness_inference(
model_id="fair-lending-rules-v1.8",
procedure="AI-FAIR.1",
input_data="application-profile-sha256:4b1e...",
output_data="fcra_violation:no_permissible_purpose",
factor_a="protected_classes_checked:7",
factor_b="fcra_section_604:violation_detected",
factor_c="fcra_purpose:NONE_ESTABLISHED",
milestone_id="MS-compliance",
phase_id="PH-underwriting",
structure_id=f"ST-loan-{loan_id}"
)
acc.add_leaf("MS-compliance", fair_result["fingerprint"],
"AI-FAIR.1", verdict="FAIL")
# Gate check -- MS-compliance now has a terminal FAIL
gate = acc.check_gate("PH-underwriting")
print(gate["passed"]) # False
print(gate["failing_milestones"]) # ["MS-compliance", "MS-decision"]
MS-doc-extraction MS-credit-scoring MS-compliance MS-decision
+---------------+ +---------------+ +---------------+ +---------------+
| AI-TOOL.1 P | | AI-CHAIN.1 P | | AI-FAIR.1 F | | (empty) |
| NHI-AGT.1 P | | AI-EXPL.1 P | | NHI-SCOPE P | | |
+-------+-------+ +-------+-------+ +-------+-------+ +-------+-------+
| | | |
v v v v
COMPLETE COMPLETE FAIL: AI-FAIR.1 NO ATTESTATIONS
|
GATE_BLOCKED
|
Decision agent CANNOT runThe compliance agent's FCRA FAIL blocks the entire pipeline. The decision agent has no leaves because it was never permitted to execute.
The blocked gate is itself a witnessed event. The GATE_BLOCKED record becomes a leaf in the structure, proving that the pipeline was halted for a specific reason at a specific time. An examiner reviewing the loan file months later can see exactly why this application was stopped and what the state of evidence was at the moment of blockage.
Assessor Note
Chain completeness: a loan decision structure without all four agent milestones populated is an incomplete evidence chain. If the decision milestone (MS-decision) has leaves but the compliance milestone (MS-compliance) does not, the decision was made without compliance evidence. Flag this immediately. A complete chain has leaves in all four milestones, and the compliance milestone's terminal verdicts are all PASS.
An SR 26-2 examiner is reviewing a denied loan application -- loan 2026-11-0042. The applicant has filed a complaint alleging discrimination. The examiner needs to understand what each agent did, what data each agent accessed, and why the denial occurred.
Call 1: Get the structure. Query the structure root for ST-loan-2026-11-0042. This returns the phase root, all four milestone roots, and the gate status.
Call 2: Expand the compliance milestone. Drill into MS-compliance to see every attestation the compliance agent recorded. The AI-FAIR.1 leaf shows disparate_impact_ratio:0.92 and protected_classes_checked:7. The NHI-SCOPE.1 leaf confirms the agent only accessed application data and the credit report -- not social media or HR records.
Call 3: Expand the credit scoring milestone. The AI-CHAIN.1 leaf shows the risk score (0.23) and model version (3.4.1). The AI-EXPL.1 leaf shows the top contributing factors: income ratio, credit history, and debt-to-income. The explanation method was SHAP with 89% coverage.
Call 4: Expand the decision milestone. The AI-HITL.1 leaf shows whether a human loan officer reviewed the denial. The factor_a field shows human_reviewer:loan_officer_7291. The AI-EXPL.1 leaf contains the adverse action reason codes provided to the applicant.
Total time: seconds, not weeks. The examiner has the complete agent chain, the data each agent accessed, the model versions, the explanation methods, the human oversight record, and the adverse action codes. Every piece of evidence is anchored in a Merkle tree with a tamper-evident root.
Assessor Note
HITL evidence for adverse actions: denied loans MUST have AI-HITL.1 evidence per ECOA adverse action requirements. If a denied loan's decision milestone lacks an AI-HITL.1 leaf, there is no evidence that a human was involved in the adverse action. Under Regulation B (12 CFR 1002.9), the lender must provide specific reasons for denial. The AI-EXPL.1 leaf in the decision milestone should contain the adverse action reason codes. Absence of either leaf in a denied loan is an examination finding.
A multi-tier proof connects any single attestation -- for example, the compliance agent's AI-FAIR.1 result for one loan -- all the way to the structure root. The proof is offline-verifiable. No database access, no API calls, no network connectivity needed.
# Generate a proof for the fair lending attestation
proof = acc.get_multi_tier_proof(fair_result["fingerprint"])
# The proof contains three tiers:
# 1. Milestone tier: fair_result fingerprint -> MS-compliance root
# 2. Phase tier: MS-compliance root -> PH-underwriting root
# 3. Structure tier: PH-underwriting root -> ST-loan-2026-11-0042 root
# Anyone with the proof can verify offline
from swt3_ai.milestone_merkle import verify_multi_tier_proof
is_valid = verify_multi_tier_proof(fair_result["fingerprint"], proof)
print(is_valid) # True
# The proof also works in TypeScript
# import { verifyMultiTierProof } from "@tenova/swt3-ai/milestone-merkle";
# const valid = verifyMultiTierProof(fairFingerprint, proof); // true
The proof is a compact data structure containing the sibling hashes at each tier needed to recompute the path from the leaf to the root. Each tier uses its own domain-separated hash prefix (following the NIST SP 800-185 derived function pattern), ensuring that a milestone hash can never collide with a phase or structure hash. The verifier recomputes each tier's hashes and confirms that the result matches the published root.
If the lender publishes the structure root (for example, in a daily portfolio rollup or in an examiner's report), any party with the proof can independently verify that the fair lending check happened, that it was part of this specific loan's pipeline, and that it has not been tampered with.
A mid-size lender processes 1,000 loan applications per day. Each application has its own structure root representing the complete four-agent pipeline. That is 1,000 structure roots per day -- 1,000 independent, tamper-evident records of multi-agent lending decisions.
The daily Merkle rollup collects all 1,000 structure roots into a single portfolio root. This is the same rollup mechanism used for daily evidence aggregation, now applied to multi-agent workflow structures.
Day: 2026-11-05
ST-loan-0001 ST-loan-0002 ST-loan-0003 ... ST-loan-1000
+-----------+ +-----------+ +-----------+ +-----------+
| root:a3f1 | | root:7c2e | | root:d914 | | root:b8a0 |
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
| | | |
+---------+----+----+---------+------- ... -------+
| |
v v
+---------------------------+
| Daily Portfolio Root |
| 2026-11-05: e7c4a91f... |
+---------------------------+
The risk committee receives one hash.
Any individual loan can be expanded with a multi-tier proof.1,000 loan decisions per day, each with four agents, each producing a structure root. One portfolio root per day for the risk committee.
The risk committee does not review 1,000 individual structure roots. They receive one portfolio root per day. If a specific loan is flagged for review (examination, complaint, audit sample), the committee drills into that specific structure root and expands the milestones to see exactly what each agent did.
Over a year, the lender produces 365 daily portfolio roots. Each one covers every lending decision made that day, every agent that participated, every compliance check that was performed or failed. The complete annual evidence set is 365 hashes.
For Risk and Insurance
Portfolio-level risk assessment using daily rollup roots: an insurer underwriting the lender's professional liability can request the daily portfolio roots for any period. A portfolio root that has not changed since publication proves that no lending decisions in that batch have been retroactively altered. During a class-action fair lending claim, the insurer can verify whether the disputed loans were part of a batch where the compliance gates were consistently passing or whether there were systemic GATE_BLOCKED events. A pattern of blocked gates that were subsequently overridden is a different risk profile than a portfolio with clean passes. The daily rollup makes this analysis possible without accessing individual loan files.
Multi-agent lending decisions touch multiple regulatory frameworks simultaneously. The table below maps each requirement to the SWT3 procedures and milestone structure that provide the evidence.
| Regulation | Requirement | SWT3 Procedure | Milestone |
|---|---|---|---|
| SR 26-2 * | Model validation: independent review of model inputs, outputs, and performance | AI-CHAIN.1, AI-EXPL.1 | MS-credit-scoring |
| SR 26-2 * | Model inventory: all models identified with version, owner, and risk tier | NHI-AGENT.1, AI-ID.1 | All milestones |
| ECOA / Reg B | Adverse action notices: specific reasons for denial, provided to applicant | AI-EXPL.1, AI-HITL.1 | MS-decision |
| ECOA / Reg B | Fair lending: no disparate treatment or disparate impact on protected classes | AI-FAIR.1 | MS-compliance |
| FCRA | Permissible purpose: credit report accessed only for legitimate credit decision | NHI-SCOPE.1 | MS-compliance |
| FCRA | Accuracy: consumer data used in the decision was accurate and current | AI-TOOL.1 | MS-doc-extraction |
| EU AI Act Art. 14 | Human oversight: high-risk AI systems must have human-in-the-loop mechanisms | AI-HITL.1 | MS-decision |
| EU AI Act Art. 13 | Transparency: deployers must understand how the AI system reaches decisions | AI-EXPL.1 | MS-credit-scoring, MS-decision |
| EU AI Act Art. 9 | Risk management: continuous identification and mitigation of risks | AI-FAIR.1, AI-CHAIN.1 | MS-compliance, MS-credit-scoring |
* SR 26-2 scope limitation: SR 26-2 (OCC Bulletin 2026-13) explicitly excludes generative AI and agentic AI systems from its scope (footnote 3: "novel and rapidly evolving"). The SR 26-2 rows above apply to traditional quantitative models in the pipeline (e.g., a logistic regression credit scoring model in Agent 2). If Agent 2 uses a large language model or agentic architecture, SR 26-2 does not apply to it. Banks using GenAI/agentic systems in lending should look to MAS AI Guidelines (which explicitly include agentic AI) or internal model governance policies for those components. A separate RFI on GenAI-specific guidance is expected from the OCC.
Each row in this table corresponds to a specific leaf in the Merkle tree. The evidence is not a narrative assertion that the lender "has a process." It is a cryptographic record of the process executing, recorded by the agent that performed the work, anchored in a structure that proves the sequence.
Assessor Note
Multi-agent drift: if the credit scoring agent's model drifts (performance degrades over time), does the compliance agent catch it? Check for AI-DRIFT.1 evidence correlated across agents. A credit scoring model that silently degrades while the compliance agent continues to pass every application is a systemic risk. Look for drift attestations in the MS-credit-scoring milestone and verify whether the compliance milestone's AI-FAIR.1 results changed in response. Cross-agent drift correlation is the difference between independent validation and rubber-stamping.