OpenClearCurrent as of 2026-10-22. Checked against its sources at least once a year (control check regulatory_currency).
OpenClear makes decisions with two kinds of model, in the sense of the Federal Reserve's SR 11-7 and the OCC's Bulletin 2011-12, Supervisory Guidance on Model Risk Management: - matching rules, which decide what becomes an exception; - scoring models, machine-learning models that give an exception an advisory fraud score. They're off until the bank turns scoring on, and they never decide an item.
How much of SR 11-7 applies depends on how the bank uses them, under its own model risk policy. This page maps OpenClear's features onto the guidance's three parts. It isn't legal advice (Compliance).
Development, implementation and use
| Guidance | What OpenClear does | Evidence |
|---|---|---|
| Documented design and limitations | Matching rules are short, pure functions with their order and reasoning documented in the architecture guide. Scoring models record their algorithm, training data size and metrics. | docs/ARCHITECTURE.md, "Matching rules"; Settings → ML models |
| Inventory | Every version of the bank's own model per network, with status, training data size, metrics and a SHA-256 of the model file. Matching-rule code and plugins in force, each with a SHA-256. | Settings → ML models; the evidence bundle's models and rules |
| Controlled implementation | A scoring model goes live only on activation. With "Sensitive settings need a second admin" on, activating a model or changing a matching rule waits for a second admin, and nobody can approve their own change. Turning scoring on is a protected change too. | Settings → Changes; change_request.* in the action log |
| Use within limits | A score is advice only: a person decides. A customer's default decision at the cut-off is a fixed "always pay" or "always return", never the score. Dual control can require a second person on every decision. | Settings; decision records |
Validation
| Guidance | What OpenClear does | Evidence |
|---|---|---|
| Outcomes analysis and back-testing | Replay runs a historical X9.37 cash letter or NACHA file through today's rules in a dry run (rolled back, so nothing is kept). It compares each item with what happened to it, and reports: agreement with history; the false-positive rate (flagged, but the bank paid it); the missed-return rate (not flagged, but returned); unhandled items; and the items that differ. Run it before and after a rule change to see what the change would have done. | Settings → Model risk; POST /api/v1/mrm/replay; mrm.replay in the action log |
| Ongoing monitoring | The anomaly-capture test presents synthetic items with known fraud vectors against the live rules in a dry run, and checks that every one is caught and that clean items aren't flagged: a duplicate check, an altered amount, a check on the wrong account, an ACH debit over its limit or from an unknown originator, and malformed files. It can run daily; a failure or a stale run shows on the Controls page. | Settings → Model risk; Controls → "Synthetic fraud caught" |
| Benchmarking | Champion/challenger: a newly trained model replaces the active one only if it scores better on the same held-out recent decisions, and it must have learned from at least 200 of the bank's own final decisions, the first model as much as a replacement. Only decisions people made are labels: a default applied at the deadline says what the account's setting is, not whether the item was fraud. The comparison is kept with the model. | Settings → ML models |
| Effective challenge | The evidence export gives an independent validator the rules, models, test runs and decisions for a period, signed, without access to the system. | GET /api/v1/audit/export |
Replay doesn't include check images (they're stored outside the database, so the dry run can't roll them back). The OCR payee comparison therefore doesn't run in a replay, and the report says so.
Governance, policies and controls
| Guidance | What OpenClear does |
|---|---|
| Roles and responsibilities | Permissions separate who manages models (admin:manage) from who decides items (exception:decide). Segregation of duties enforces it. |
| Change records | Every activation, rule change, approval and rejection is in the hash-chained, signed action log. |
| Reporting | Model-risk runs and the control status go into each evidence export. |
Built from docs/compliance/sr-11-7.md in the OpenClear repository. Last changed October 22, 2026.