A FINRA examiner shows up. Regulation Best Interest. They want the full suitability reasoning behind trade T-88421 — every input to the model's recommendation, the KYC profile in force, the rep's added reasoning, and the model card. As of February 19, 16:42, the moment of recommendation.
Most wealth-management stacks can produce the first three. The fourth — proof that the model card itself hasn't been silently edited since the trade — is the question your stack probably can't answer with certainty. The model lives in MLflow. The card lives in a Notion page. The training-data fingerprints are in S3 (somewhere). Reproducing the exact card as it stood on February 19, with cryptographic non-modification proof, takes most firms a week of model-risk team time. And even then, the answer is "we believe it hasn't been edited," not a mathematical proof.
So most firms hedge. Legal drafts a careful response. The examiner pushes back. The firm settles a small fine.
What Reg BI is actually asking
The care obligation in Reg BI has four prongs. Three of them — reasonable basis, suitability for the customer, and conflict of interest — are about the inputs to the recommendation. The fourth is about the integrity of the recommendation process: the firm must have a reasonable basis to believe the recommendation was in the customer's best interest at the moment it was made.
That last clause is bitemporal. The examiner doesn't want to know what's in the customer's best interest today. They want to know what was in the customer's best interest on February 19. The model version. The training data. The firm's risk policy. The customer's KYC. The market state at T-1 close.
If your firm runs on a bitemporal graph, all of that is one query.
The model-card integrity proof
The harder question is whether the model card itself has been edited since the trade. In a chained-audit-log system, the answer is one procedure call:
CALL db.propertyHistory('model:alpha-rebalance-v7.3.1', 'card_uri')
YIELD value, validFrom, recordedAt
RETURN value, validFrom, recordedAt
CALL db.verifyAclChain('model:alpha-rebalance-v7.3.1')
YIELD tampered
RETURN tamperedThe first proc returns the history of the model card URI. For a well-managed model, it's one row: the card published at 2025-10-12, signed by the model-risk officer, never edited.
The second proc rehashes the chain. If any property of the model node had been edited between October and today — including the card URI, the bias-test results, the training-data fingerprint — the chain would show it. For a model that hasn't been re-fit since release, the chain proves zero edits. Mathematically.
This is the moment your firm stops settling and starts winning these examinations.
The lineage walk
For the inputs to the recommendation, db.derivedFrom on the trade-rec node returns every input. The customer's KYC profile, the current holdings, the previous day's market close, the model and its training-data fingerprint, the firm's risk policy in force. Every input cryptographically signed at capture.
The examiner doesn't have to take your word for any of it. They walk the graph.
Regulation S-P portability
While the FINRA examination is in flight, the customer asks for their data under Reg S-P. db.subjectExport packages every record — KYC, holdings, every recommendation and the full reasoning behind each — into a signed tarball. Five seconds, one call. The customer gets a machine-readable bundle. Your records-retention chain stays intact for the FINRA review.
The numbers
A six-week, $220,000 examination response becomes a sixty-second answer. Reg BI care obligation, cryptographically defensible. Model card integrity, mathematically provable. The model risk you used to hedge against — silent re-fits, lost training data, undocumented overrides — is gone, because the chain doesn't let any of those things happen quietly.