The decisioning stack for regulated payments
Four modules, one system of record. Rules in, decisions out, cases handled, everything logged — built for the analysts, MLROs and risk leads who run a payments compliance operation.
An inbound event is evaluated against your ruleset and risk model, screened, and resolved to a verdict with reason codes. Non-approvals open a case; every step is written to the audit trail. Illustrative of the platform flow.
Decisioning engine
Score every applicant and transaction against your policy in real time.
The decisioning engine evaluates an inbound event against a versioned ruleset and risk model, returns APPROVE / REVIEW / BLOCK in sub-second time, and attaches the reason codes that explain the outcome. Rules are authored and tuned by your risk team, not hard-coded by us — thresholds encode your institution's own appetite. Because every decision is explainable and versioned, you can show an examiner exactly which policy produced which result.
Who uses it Risk & policy leads author rules; engineers call the API; analysts read the reason trail.
- ▸ Versioned rules + risk scoring
- ▸ Sub-second, deterministic verdicts
- ▸ Reason codes on every call
- ▸ Shadow-mode testing (roadmap)
Screening pipeline
Sanctions, PEP and adverse-media screening with tunable matching.
A party or transaction fans out to parallel checks — sanctions and watchlists, politically exposed persons, adverse media, and your internal blocklists. Matches are scored against a threshold you control, low-risk results auto-clear, and anything above the line opens a case. Ongoing monitoring re-screens as lists and risk change, so a party that clears today is re-checked when a list updates.
Who uses it Compliance configures thresholds and list coverage; analysts work the hits that surface.
- ▸ Sanctions & watchlists
- ▸ PEP & adverse media
- ▸ Ongoing monitoring
- ▸ Auto-clear low risk
Case operations
A dense operator console for the people who work alerts all day.
Every non-approval and screening hit lands in a unified queue with priority and SLA. Analysts pick up cases, gather evidence and notes, link related parties and prior cases, and disposition as cleared, blocked or escalated — each with a recorded rationale. Escalations route to an MLRO for the suspicious-activity decision. The console is built for density and keyboard flow, because these are people who live in it.
Who uses it Analysts triage and investigate; the MLRO owns escalations and the reporting decision.
- ▸ Unified queue & assignment
- ▸ SLAs & prioritisation
- ▸ Evidence, notes & linking
- ▸ Four-eyes approval (roadmap)
Audit & governance
Append-only records that stand up as examiner evidence.
Every input, score, reason code, decision, override and case action is written to an append-only audit trail — timestamped and attributed to a user or key. The application writes audit entries and never updates or deletes them. Records are structured so a customer can reconstruct why any outcome was reached and hand an examiner a clean chain of evidence. Cryptographic tamper-evidence (hash-chaining / WORM export) is on the roadmap.
Who uses it MLROs and internal audit pull evidence; regulators receive exportable records.
- ▸ Append-only trail
- ▸ Override & rationale capture
- ▸ Evidence export
- ▸ Retention controls
Inside the screening pipeline
Screening is not a single lookup — it is parallel checks whose matches are scored and routed. You control the threshold, the list coverage and what auto-clears, and monitoring keeps working after the first pass.
Parallel checks fan out from a single party or transaction; matches are scored against your threshold and either auto-cleared or routed to a case. Ongoing monitoring re-runs as lists change.
From alert to regulatory report
An alert is only the start. Case operations carry it through triage, investigation and disposition to the point where an MLRO decides whether a suspicious-activity report is warranted — with the whole chain recorded.
Alert
Screening hit or rule trip raises an alert
Triage
Queued, prioritised and assigned by SLA
Investigate
Evidence, notes and linked parties gathered
Disposition
Cleared, blocked or escalated with rationale
Report
MLRO files SAR/STR to the FIU (customer files)
Sentrix runs the operational workflow up to the reporting decision. The regulatory filing to the FIU is made by the customer's MLRO — Sentrix is the tooling, not the reporting entity.
Who operates in Sentrix
Analyst
Lives in the case console — triages the queue, investigates alerts, gathers evidence and dispositions routine cases within SLA.
MLRO / compliance lead
Owns escalations and the suspicious-activity decision, files the SAR/STR to the FIU, and pulls audit evidence for examiners.
Risk & policy lead
Authors and tunes the rules and thresholds that encode the institution's risk appetite; reviews decision quality over time.
Engineering
Integrates the decisioning API into onboarding and payment flows and manages keys — a few endpoints, JSON in and out.
How it fits your stack
Sentrix sits between your systems and your operators. You call the decisioning API from onboarding and payment flows; screening, cases and audit run inside the platform; your analysts and MLRO work in the console and export evidence. It is a decisioning and case-operations layer, not a replacement for your core or ledger.
Runs on Vercel (edge/serverless) · Neon Postgres · single primary region today; customer-selectable residency on the roadmap
High-level architecture. Integration is via a workspace-scoped REST API today; webhooks and customer-selectable data residency are on the roadmap. See the API reference for the live surface.
Items marked (roadmap) are planned and not yet available. In the current evaluation environment, screening providers run in sandbox and decision, screening and case outputs are simulated — they must not be used for real compliance, onboarding or payment decisions. See the API reference for the endpoints that exist today, and the Information Security page for the controls behind the platform.