Introduction

SpeculaPro watches the money moving through a payment provider, fintech or bank, and tells the compliance team when something looks like money laundering or fraud. It then gives them a place to investigate, decide and — when the law requires it — report to the regulator.

These docs are written for everyone who touches it: compliance officers, analysts, the people who write and tune rules, and the engineers who run it. You do not need to be technical, or an AML specialist, to follow the guides. Where a term of art appears, it is explained on the spot or in the glossary.

What is built, and what hasn’t run for real yet

The product described in these docs is built: sending data, rules, alerts and cases, real-time decisions, sanctions screening, regulatory reports, data protection tools, single sign-on and self-hosting all work, and the pages show the real screens. What SpeculaPro has not had yet is a live institution: no release has been published and the performance targets have only been measured on a laptop. Where a feature is a first stage, or isn’t built, the page says so. See Status and roadmap for the full list.

Start here

New to transaction monitoring? Read these two first, in order:

1. What is transaction monitoring? — AML versus fraud, why regulators require it, and what an STR is.
2. How SpeculaPro works — one mobile money transfer followed from the moment it arrives to the report filed with the regulator.

Then pick your path.

If you are the MLRO or compliance officer

You are accountable for the programme, so you need to understand what decides an alert and who can change it.

1. Roles and permissions — who can approve rules, close cases and submit reports, and why no one person can do all three.
2. Rules and versions — how a rule change is proposed, approved by a second person and frozen.
3. Escalation and SLAs — how cases reach you.
4. Audit trail — what you can show an examiner.
5. Regulatory reporting — drafting, approving and filing an STR or CTR.
6. Sanctions and PEP screening and Data protection — the two programmes that sit beside monitoring.

If you are an analyst

You work the alert queue and investigate cases.

1. Alerts and cases — what an alert is, why several hits become one alert, and how alerts roll into cases.
2. Risk designations — PEPs, sanctioned parties and other flags that change how a customer is treated.
3. Suppressions — the right way to stop known-good activity from alerting again and again.
4. The rule library — what each rule is looking for, so you know why it fired.
5. Working alerts and cases — the screens you use every day, step by step, and the playbooks for common investigations.

If you write or tune rules

1. Rules and versions — drafts, approval, shadow mode.
2. The rule library — every starter rule, its parameters and its false-positive traps.
3. Lists and money and currencies — the two things most thresholds depend on.
4. Managing rules — installing a pack, tuning, shadow mode, backtesting, writing your own rule and using risk-model scores.

If you connect your systems to it

1. Sending data — the ingest API, file imports, Kafka topics, file drops and change data capture.
2. Real-time decisions — asking for allow, step up, review or block before a payment goes ahead.
3. The API reference and webhooks.

If you run SpeculaPro yourself

1. Architecture overview — the moving parts.
2. Self-hosting — requirements, setup, configuration and upgrades.
3. Workspaces and tenancy — how to create the first workspace and administrator.
4. Security model — encryption keys, sign-in and isolation.

How the docs are arranged

Section	Covers
Getting started	What transaction monitoring is, how SpeculaPro works, status and the glossary.
Core concepts	Ideas that apply everywhere: workspaces, roles, rules, alerts and cases, escalation, suppressions, designations, lists, money, risk models, data residency, the audit trail.
Working alerts and cases	The daily screens: the command center, the alert queue, the optional AI assistant’s advice, cases and their evidence files, transactions, analytics and notifications.
Customers and lists	Customer profiles, risk designations and the lists rules read.
Sanctions screening	Lists, matching, providers and reviewing a potential match.
Real-time decisions	Asking SpeculaPro before a payment goes ahead, and the decision log.
Regulatory reporting	STRs and CTRs: drafting, approval and filing with your FIU.
Data protection	Retention, legal holds, data subject requests, registers and breaches.
Administration	People, roles, approvals, single sign-on, API keys, webhooks, jurisdictions and workspace settings.
Sending data	The ingest API, file imports, Kafka topics, file drops and change data capture.
Rule library	Every starter rule, grouped A to I, with what it catches, its parameters and how to tune it.
Managing rules	Packs, tuning, approval, shadow mode, backtesting, scheduled rules, custom rules and risk models.
Playbooks	Step-by-step investigations for common situations.
Architecture	How the system is built — for engineers and technical evaluators.
Self-hosting	Running SpeculaPro on your own infrastructure.
Provider console	For an organisation running SpeculaPro as a hosted service for others.
Security model	Tenant isolation, encryption, sign-in, API keys and support access.
API	Integrating your systems with SpeculaPro.

Things worth knowing up front

SpeculaPro keeps its own copy of your data. You send it transactions, customers and accounts; it never reaches into your core banking system. That copy is what lets it prove, years later, exactly what a rule saw when it fired. See Data ownership and ingestion.

You can start before your integration is ready. Your systems normally send data through the ingest API, a Kafka topic, a file drop or change data capture, but an administrator can also load customers and transactions from a CSV or JSON file in Settings → Data import. That is enough to run a pilot or load history. See Importing a file.

A rule never changes in place. Every edit creates a new version, a different person must approve it, and once approved its logic is frozen. Every alert points at the exact version that produced it.

Nothing important is ever deleted. Suppressed hits are kept, revoked designations are kept, the case timeline and the audit log cannot be edited. If you are looking for a delete button on any of these, it does not exist by design.

Two people, not one. Approving a rule, approving a suppression, closing a high-risk case and approving a regulatory report all need a second person who is not the one who did the work. This is called the 4-eyes principle, and the database itself enforces it.

Thresholds in the starter rules are placeholders. They must be calibrated for your customers and checked against your regulator’s guidance before you rely on them. See the rule library.

Related

• Glossary
• Status and roadmap
• How SpeculaPro works