How SpeculaPro works

The easiest way to understand SpeculaPro is to follow some money through it. This page tells the story of one customer, step by step, and links each step to the page that explains it fully.

A worked example, not a screenshot tour

The story describes what the system does, and every step in it is built. Each step links to the page that shows its screens. All names and amounts are invented.

The setup

Kweku Pay is a payment service provider in Accra. It runs mobile money wallets and pays out to bank accounts. Kweku Pay uses SpeculaPro, in a workspace called kwekupay, with the core and gh-psp rule packs installed.

Ama opened a Kweku Pay wallet five weeks ago. She is at KYC tier 2 and told Kweku Pay she is a trader expecting about GHS 6,000 a month.

1. A transaction arrives

On Monday at 09:14 Ama receives GHS 450 from a wallet she has never dealt with.

Kweku Pay’s system sends the transaction to SpeculaPro’s ingest API (an institution without an integration yet could import a file instead). It says who, how much, in what currency, which channel (momo), which direction (in), and Kweku Pay’s own reference for it — the external id.

SpeculaPro:

• checks it has not seen this external id before. If Kweku Pay’s system retries after a network blip, the second copy is recognised and ignored, so nothing is counted twice;
• converts it into a standard shape, so the same rules work for every institution;
• encrypts the counterparty’s wallet number and keeps only a keyed fingerprint for matching, so the number never travels or sits in the database in clear;
• stores the amount in minor units — 45,000 pesewas — plus the amount in the workspace’s base currency (here also GHS). See Money and currencies;
• puts it on the Kafka stream under Ama’s account, so everything about her account is processed in order.

More: Data ownership and ingestion.

2. Her running totals are updated

The feature store keeps running counters for every account, customer and counterparty: how many transactions, how much money, how many different senders — in hourly and daily slices, going back 180 days.

After Monday’s payment, Ama’s counters show: 1 inbound transfer today, 1 distinct sender, GHS 450 received.

More: Feature store.

3. The rules look at it

Every enabled post-event rule now asks its question about this transaction, using those counters. For example:

• D1 Fan-in — “Has this account received money from at least N different senders in the last window?”
• C5 Rapid in-and-out — “Has at least 90% of what came in left again within 24 hours?”
• G4 Wallet swept to bank — “After many inbound payments, has most of the money been moved out to a bank in one go?”

On Monday, nothing matches. Ama’s activity is normal.

More: Rule engine, Rule library.

4. The pattern builds

Over Monday, Tuesday and Wednesday, Ama receives 23 transfers from 21 different wallets, GHS 250 to GHS 900 each — GHS 13,640 in total. On Wednesday evening she moves GHS 13,000 out to a bank account.

Now two rules match:

Rule	Why it matched
D1 Fan-in	21 distinct senders in 3 days, above the threshold of 15
G4 Wallet-to-bank sweep	95% of three days’ inbound P2P swept out to a bank in one go

A third rule, F5 Transaction inconsistent with declared profile (GHS 13,640 in three days against a declared GHS 6,000 a month), also ships in the core pack. It runs once a day on a schedule instead of on each transfer, so it would add its own hit at its next run if her totals pass its thresholds.

Each match is a rule hit. Each hit records the exact rule version, the counter values the rule saw, and the parameters it used — so anyone can check later why it fired.

5. The hits become one alert

Two separate hits about the same customer in the same few days would mean two analysts looking at the same thing. Instead:

1. SpeculaPro checks for a suppression covering Ama or these rules. There is none.
2. The hits merge into one alert about Ama, carrying the highest score and the highest severity of the hits, both rule names, and the total value of the transactions behind them. Any further hits about Ama are added to the same alert while it is open.

More: Alerts and cases.

6. The alert becomes a case

The alert waits in the alert queue, riskiest first. Efua, an analyst, opens a case from it. Ama has no active case, so a new one is created — SP-2026-000187 — at level 1, assigned to Efua. The alert’s severity is high, so the case’s priority is high too. High priority gives the case a deadline (SLA) of 24 hours.

From now on, any new alert about Ama joins this case automatically until it is closed.

7. An analyst investigates

Efua works the case. She can see the alert, the two hits and the transactions behind them. She notices that:

• several of the senders also sent money to two other new wallets the same week;
• Ama’s wallet was opened with the same device as one of those wallets.

She writes her findings as comments on the case. Each comment, assignment and status change is an event on the case’s timeline, which can never be edited or deleted.

Why the analyst can’t just close it

Efua holds the Analyst role. It lets her work cases but not close them — closing needs the Senior analyst or MLRO role. See Roles and permissions.

8. The case is escalated

Efua escalates the case. It moves to level 2, then — because the senior analyst agrees it looks like a money mule pattern — to the MLRO.

More: Escalation and SLAs.

9. The decision and the report

The MLRO, Kofi, decides the activity is suspicious. He:

1. sets the case disposition to report filed;
2. drafts a Suspicious Transaction Report from the case — the customer, the transactions and the narrative are carried over;
3. sends the report for approval. A second person with the right permission approves it — it cannot be Kofi himself;
4. exports it in the goAML format and submits it to the FIC. The FIC’s reference is recorded on the report.

Ama is never told

Nothing about the case or the report is ever sent to Ama. Telling her would be tipping off, which is an offence.

10. What remains

Years later, an examiner asks why Ama was reported. Kweku Pay can show:

• the transactions exactly as SpeculaPro received them;
• the frozen rule versions and parameters that fired, and the counter values they saw;
• every comment, escalation and decision on the case, with who did it and when;
• who approved the report, and the FIC’s acknowledgement.

More: Audit trail.

And real-time fraud?

If Kweku Pay also uses the decision API, the same platform can stop fraud before money moves. Suppose someone swaps Ama’s SIM card and, an hour later, tries to send GHS 5,000 to a new recipient from a new phone.

1. Kweku Pay’s app has already told SpeculaPro about the SIM swap, as an account event.
2. Before sending the money, the app asks SpeculaPro for a decision.
3. Two rules match: G3 Payout soon after a SIM swap, which blocks, and H2 New device paying a new payee a large amount, which asks for a review. The strictest answer wins, so SpeculaPro answers block, with both rules as reasons.
4. The app stops the transfer and tells Ama to call support. Kweku Pay’s fraud desk is notified by webhook, and the block also becomes a fraud alert for the team to investigate.

If SpeculaPro can’t finish its checks within the time Kweku Pay allows, it answers with Kweku Pay’s chosen fallback instead of keeping the customer waiting. See Real-time decisions.

Related

• What is transaction monitoring?
• Components and Kafka topics
• Alerts and cases
• D. Mule and network patterns