Guides by role

Sentinel is used by five kinds of people. Find yours below. Regulators and auditors never log in; they read what you give them.

Sentinel has no user accounts yet. Everyone signs in to the dashboard with an API key, and "a different person" means "a different key". Give each person their own key.

Founders and compliance leads

Sentinel is your AML programme's engine and its paper trail. Regulators judge you on whether controls exist, whether they work, and whether you can show evidence of both.

• Start with Monitoring and Screening. Cases and reporting are planned.
• Agree with your engineers what a review decision means for you: hold the payment, or allow it and watch.
• Decide who proposes alert closures and who approves them, and give each of them a key.
• License a real sanctions and PEP list. Sentinel ships only a synthetic sample.

Analysts

• Work the Alerts queue from the top. For each alert, ask whether the reasons make sense for this customer.
• Check occurrences. An alert can cover several decisions from the same customer.
• Write notes for someone who wasn't there: what you checked, what you found, and why you're closing it the way you are.
• You propose the disposition (false_positive, escalated or reported). A reviewer approves it.
• Screening matches show up in the queue as alerts with the event type screening. Work them on the Screening screen, one match at a time. Compare the name, birth year and country with what you know about the customer, look at the near misses too, and mark each match True match, False positive or Need more info with a note.
• A false positive waits for a reviewer. Once every match on a screening is cleared and approved, its alert closes by itself.

Reviewers

• You're the second pair of eyes. Read the notes, check the reasons, and reject the closure if anything is thin. A rejected alert goes back to in_review.
• You also approve screening matches cleared as false positives. Read the note and the match, then approve, or send it back for another look.
• You activate rule changes. Look at the backtest before you approve.
• You can't approve your own closure, your own cleared match or your own rule.

Engineers

• Run Sentinel locally and send an event. The quickstart takes about 15 minutes. Then wire POST /v1/events?mode=sync into your payment flow.
• Always send an idempotency_key, and reuse it on retries.
• Use sync mode for anything you want scored. Async mode only stores events today.
• Send source.entity_id on every money event. Velocity features and alert grouping depend on it.
• Handle all three decisions: allow, review and block.
• Decide, with your compliance lead, what happens when Sentinel can't be reached, and test it.
• Never show customers why a payment was stopped.
• Give each service its own API key, so you can revoke one without breaking the rest.
• Poll GET /v1/alerts for now. Webhooks are planned.

Admins

• Install Sentinel and create the first key. See Installation.
• Create a key for each person and service on the Developers → API keys screen, and revoke keys as soon as they're no longer needed. Revoked keys stay listed for the audit trail.
• Run sentinel-admin audit verify when auditors ask whether the log is intact.
• Load and update screening lists with sentinel-admin screening load.
• Back up PostgreSQL, and test a restore.

Screens in the dashboard

The designs also include Cases, Entities, Network graph, Reports, Connectors, Team and roles, Audit log, and Licence and usage screens. None of those are built yet.