How it works
Six layers, one record.
Written for the engineer who owns the rails. Each layer says what it reads, what it writes, what its API surface is, and what it keeps. Nothing here needs a new integration on your side: the platform reads the events you already emit and acts through the API you already have.
The six layers
What each layer reads, writes, and keeps.
The webhook events your rails already emit: ACH, wire, international wire, real-time, book transfers, checks, identity verification, account overdraft and frozen, card decisions. Verified on the raw body with the endpoint's signing secret, deduplicated by event id, safe under redelivery.
An append-only event store, and the normalized objects behind it: programs, entities, accounts, counterparties, transfers. Statuses are stored exactly as your API names them: manual review, hold, returned, completed, and the verification states from unverified through denied.
One webhook URL per program. An admin API to create tenants and programs and to register the endpoint against your sandbox with your own key.
Every event, its signature result, when it arrived, and when it was processed.
The transfer, return, review, hold, reserve, verification, and screening history of each program over a rolling window.
A snapshot per program: every KRI with its value, its n, its threshold, and a status of ok, watch, breach, or unmeasured. Rolled up into a Program Skoor.
Snapshot on demand or on a schedule; latest snapshot per program.
Every snapshot kept, so a KRI can be read as it was on the day a decision was made.
For each transfer: the program's history, the entity's verification and screening state, the counterparty's history, velocity, amount against expected activity, rail, and geography.
A Transaction Skoor on the transfer, and Entity, Counterparty, and Agent Skoors on the actors around it. Each carries its inputs, its signals with weights, its version, its n, and its confidence. Null where history is too thin.
Score on ingest; backfill per program; read the breakdown of any Skoor.
The inputs and the version are stored with the number, so any Skoor can be recomputed and explained later.
Alerts from the detectors, the band, the presence of a hard signal, and the program's history.
A route for every alert: automated or reviewed, under a named policy version. For the reviewed queue, a drafted narrative (what happened, what the evidence shows, what was checked, what is recommended) with the model name and its confidence, or a template with neither when no model is configured. A person signs.
The queue, the alert, the decision. Every decision carries the operator's name.
Every disposition chained to the one before it: narrative, evidence, policy version, who decided, and whether the person overturned the draft.
A signed decision and the policy's rule for the action requested.
Clear or cancel a held transfer, pause a card, suspend a card account, freeze an account, send a request to a program, assemble a periodic review. Through your bank's own API with your own keys. Sandbox keys until you say otherwise.
Request an action; approve it. Freeze, suspend, and requests to a program need a second, distinct approver.
Every action chained with who requested it, who approved it, and what the bank's API returned.
The same data, scoped to one program.
The program's own view: its KRIs, its Skoors, its open requests, its queue.
The same pages and endpoints, scoped by program.
The same record, so the bank and the program are reading the same numbers.
Program KRIs
Fifteen indicators, each with its n.
Computed per program over a rolling 60-day window. The three ACH return rates use the network’s own thresholds. Reserve coverage uses the rule a bank already applies before a program may originate debits. A KRI with no observations is reported as unmeasured, not as zero.
The Skoors
Five numbers, one scale.
Every Skoor is 0 to 100 in four bands: Clear 0–29, Review 30–69, Hold 70–100, and Unscored, which is null. Every Skoor carries its inputs, its version, its n, and its confidence. The full definition and signal weights →
The boundary
Policy v1, as the platform applies it.
The line between decisions the platform makes alone and decisions that wait for a person is data, not code: a named version applied the same way to every alert until the next version. The automated side never widens on its own.
Triage: a draft, then a signature.
For every reviewed alert the platform drafts the narrative a compliance officer would write: what happened, what the evidence shows, what was checked, and what is recommended, with a confidence. The draft is produced by Claude and the model name is recorded with it; when no model is configured the platform writes a template from the evidence with no model and no confidence. A person signs every decision, and the record notes when the person overturned the draft.
The record
Chained, verifiable, exportable.
Dispositions and actions are each hash-chained per bank. The chain can be verified on demand and the first break, if any, is reported. Any date range exports for an examiner as one file with the alerts, the decisions, the actions, and the policy version in force. Monthly metrics carry their n.
Column is the first integration, built on its public API and sandbox.
Bring the engineer who owns the rails.
A walkthrough is forty minutes. We map your event families onto the six layers and leave you with the line between automated and reviewed written down.