A. Thresholds and reporting

Threshold rules are the simplest rules in the library and usually the first ones a compliance team switches on. They ask one question: is this amount bigger than it should be?

They matter for two reasons:

• Regulatory reporting. Some transactions must be reported regardless of suspicion — for example large cash transactions (cash transaction reports, CTRs). Threshold rules find the candidates.
• Risk. Most money laundering eventually involves moving a large amount. A large amount alone is not suspicious, but it is the moment worth a second look.

Thresholds here are examples, not defaults

Amounts on this page (GHS 50,000 and so on) are illustrations only. Set every threshold for your own customers, and take regulatory thresholds from current FIC guidance. See Tuning and calibration.

Rules in this category

ID	Rule	Mode	Status
A1	Large single transaction	RT/PE	Ships (core, post-event)
A2	Large cash transaction (CTR candidate)	PE	Ships (core, post-event)
A3	Large cross-border transfer	PE	Ships (core, post-event)
A4	Transaction above the customer’s KYC tier limit	RT	Ships (gh-psp, post-event; and as A4-RT, real-time, from gh-psp 1.1.0)
A5	Aggregate daily or monthly value above tier limit	RT/PE	Ships (gh-psp, post-event)
GB2	Large foreign-currency cash	PE	Ships (gh-bank, post-event)

---

A1 Large single transaction

Ships today: core.large_transaction in the core pack

Parameters are threshold (default GHS 50,000) and channels (default: every channel). There is no customer-segment filter yet. Exact defaults and logic: Pack contents.

What it looks for: one transaction whose amount is above a threshold you set, on the channels and for the customer segments you choose.

Example

With threshold_amount set to GHS 50,000, channels[] set to transfer and momo, and segments[] set to retail:

• ✅ Fires: a retail customer sends GHS 62,000 by bank transfer.
• ❌ Does not fire: a retail customer sends GHS 45,000 (below the threshold).
• ❌ Does not fire: a corporate customer sends GHS 400,000 (corporate is not in segments[]).

Parameters

Parameter	Meaning	How to tune
threshold_amount	Amount above which the rule fires, in your base currency	Start well above normal behaviour for the segment — for example around the top 1% of transaction values
channels[]	Which channels count (mobile money, card, transfer, cash, agent, …)	Leave out channels where large amounts are routine for this segment
segments[]	Which customer segments the rule applies to	Create separate copies of the rule for segments that need very different thresholds

Mode and pack: real-time (to hold or review before approval) or post-event (to alert afterwards).

False positives: salary payments, property purchases, school fees at the start of term, and known business customers. Prefer narrowing segments[] over raising the threshold for everyone; use a suppression for a specific customer with a documented reason.

Data it needs: amount, currency (converted to base currency), channel, and the customer’s segment.

---

A2 Large cash transaction (CTR candidate)

Ships today: core.large_cash in the core pack

Counts cash-type transactions (cash_in, cash_out, deposit, withdrawal) through cash channels (cash, agent, branch, atm). threshold defaults to GHS 50,000. Confirm the real figure with current FIC guidance. Exact defaults and logic: Pack contents.

What it looks for: a cash deposit or withdrawal above the regulatory cash reporting threshold. Its purpose is to make sure every transaction that must be reported is found — it is a reporting control as much as a risk rule.

Example

With threshold_amount set to the current FIC cash threshold (shown here as GHS 50,000 for illustration) and cash_channels[] set to cash and agent:

• ✅ Fires: a customer deposits GHS 55,000 cash over the counter.
• ✅ Fires: a wallet holder cashes out GHS 51,000 at an agent (if agent cash-out is in cash_channels[]).
• ❌ Does not fire: a GHS 55,000 bank transfer (not a cash channel).

Parameters

Parameter	Meaning	How to tune
threshold_amount	The cash reporting threshold	Take this from current FIC guidance, confirmed by your compliance officer. Do not “tune” it for alert volume
cash_channels[]	Which channels count as cash	Include every way physical cash enters or leaves: counters, agents, ATMs where relevant

Mode and pack: post-event.

A2 is not a suspicion rule

A transaction above the cash threshold may need to be reported even if nothing about it is suspicious. Do not suppress A2 hits to reduce workload — that would hide reportable transactions. Your cash reporting obligations and process must be confirmed with your compliance officer.

Pair A2 with B1

People who know the reporting threshold often stay just under it. B1 looks for repeated deposits just below the same threshold, so set them up together with the same number.

Data it needs: amount, channel (so cash can be identified), direction.

---

A3 Large cross-border transfer

Ships today: core.large_cross_border in the core pack

Parameters are threshold (default GHS 20,000) and home_country (default GH). There is no list of excluded countries yet. Exact defaults and logic: Pack contents.

What it looks for: a transfer to or from another country above a threshold.

Example

With threshold_amount set to GHS 100,000 and exclude_countries[] empty:

• ✅ Fires: a customer sends the equivalent of GHS 130,000 to a beneficiary in another country.
• ❌ Does not fire: a GHS 130,000 transfer to another account in Ghana.

Parameters

Parameter	Meaning	How to tune
threshold_amount	Cross-border amount above which the rule fires	Usually lower than the domestic A1 threshold, because cross-border flows carry more risk
exclude_countries[]	Countries that should not trigger this rule	Use carefully, for example for a corridor that is routine and low-risk for your business. High-risk countries are covered separately by E1

Mode and pack: post-event.

False positives: importers paying regular suppliers abroad, tuition paid to foreign universities. Segment business customers separately.

Data it needs: amount, counterparty country (or transaction country).

---

A4 Transaction above the customer’s KYC tier limit

Ships today in two forms, both in the gh-psp pack

• gh.kyc_tier_single_limit (A4) runs post-event: it raises an alert and cannot block. It checks money in and out. Pack contents.
• gh.kyc_tier_limit_realtime (A4-RT), new in gh-psp 1.1.0, runs in real-time decisions and answers block, so an over-limit payout is refused before it happens. It checks outgoing money only. Pack contents.

Both read limits, which maps each tier to its single-transaction limit (defaults: tier 1 GHS 1,000, tier 2 GHS 5,000, tier 3 GHS 20,000), and both skip customers whose tier is unknown or not in limits. They are separate rules, so tuning one doesn’t change the other: keep their limits in step.

What it looks for: a single transaction larger than the customer’s KYC tier allows. In Ghanaian mobile money, wallets are commonly held at different KYC levels with different transaction limits; a customer with minimal verification should not be able to move large sums.

Example

With per-tier limits configured so that tier 1 allows at most GHS 1,000 per transaction (an illustration — use the limits your institution actually applies):

• ✅ Fires: a tier-1 wallet holder attempts a GHS 3,000 transfer. In real-time mode this can be blocked or sent for review before it happens.
• ❌ Does not fire: a tier-3 wallet holder sends GHS 3,000.

Parameters

Parameter	Meaning	How to tune
per-tier limits (daily / monthly)	The maximum allowed per KYC tier	Copy exactly the limits your institution’s KYC policy sets for each tier
kyc_levels	Which tiers the rule applies to	Usually the lower tiers

Mode and pack: post-event (A4) and real-time (A4-RT), both in gh-psp. Workspaces that installed gh-psp 1.0.0 get A4-RT by upgrading the pack.

Why this matters even if your core system enforces limits

Your core system may already refuse over-limit transactions. A4 still adds value: it catches transactions where the limit was bypassed (manual overrides, a misconfigured product), and an attempted over-limit transaction is itself a useful signal.

Data it needs: the customer’s KYC level, kept up to date as customers are re-verified.

---

A5 Aggregate daily or monthly value above tier limit

Ships today: gh.kyc_tier_daily_limit in the gh-psp pack

Checks the 24-hour outflow across all the customer’s accounts against a per-tier limit (defaults: GHS 2,000 / 10,000 / 50,000). There is no monthly limit yet. Exact defaults and logic: Pack contents.

What it looks for: the total a customer has moved over a day or month going above their tier limit, even if no single transaction did.

Example

With a tier-1 limit of GHS 5,000 per day (illustration) and window set to one calendar day:

• ✅ Fires: a tier-1 customer makes six transfers of GHS 900 in a day (GHS 5,400 in total).
• ❌ Does not fire: the same six transfers spread over two days.

Parameters

Parameter	Meaning	How to tune
window	The period totals are calculated over (for example a day or a month)	Match your KYC policy’s periods. “Per day” is evaluated in the tenant’s timezone (Africa/Accra for Ghana)
per-tier limits	The allowed total per tier	Copy from your KYC policy

Mode and pack: real-time or post-event.

Data it needs: amount, KYC level, and a full history of the customer’s transactions in the window — make sure every channel is being sent to SpeculaPro, or the totals will be too low.

---

GB2 Large foreign-currency cash

Ships today: ghb.fx_cash in the gh-bank pack

Post-event, alerts about the customer. Fires on a cash deposit, withdrawal, cash-in or cash-out at a branch, ATM or cash counter in US dollars, euros or pounds of 10,000 or more in that currency, or, if you set one, at or above a base-currency equivalent. Exact defaults and logic: Pack contents.

What it looks for: large foreign-currency cash, which banks report separately from cedi cash. Unlike A2, it measures the amount in the transaction’s own currency, not after conversion to cedis.

Example

With the defaults (threshold 10,000, currencies USD, EUR and GBP):

• ✅ Fires: a customer deposits USD 12,000 in cash at a branch.
• ❌ Does not fire: USD 12,000 received by international transfer (not cash).
• ❌ Does not fire: a cedi cash deposit of any size: that is A2’s job.

Parameters

Parameter	Meaning	How to tune
threshold	Threshold in the transaction’s own currency, in whole units	The same figure applies to each listed currency: EUR 10,000 and GBP 10,000 are not converted from USD 10,000
threshold_base	Or at or above this amount in your base currency, converted at the transaction’s FX rate. 0 (the default) turns it off	Set it if the FIC’s threshold is “USD 10,000 or its equivalent”: for example the cedi value of USD 10,000, so a EUR or GBP deposit worth that much also alerts
currencies	Currencies to watch	Any currency

The amount is read in the transaction’s own currency with that currency’s own decimals (since gh-bank 1.1.0, as the CEL variable txn.amount_original), so currencies with no or three decimal places, such as JPY or KWD, are measured correctly. A transaction in your base currency is never counted.

Confirm the threshold with the FIC

The 10,000 default reflects the FIC’s foreign-currency cash reporting threshold as we understand it. Confirm the current figure, and whether it applies per currency or as a US-dollar equivalent, with the FIC.

Mode and pack: post-event, in gh-bank 1.0.0; threshold_base and correct decimals since 1.1.0.

Data it needs: currency and amount_minor as transacted, type (deposit, withdrawal, cash_in or cash_out) and channel (cash, branch or atm).

Related

• B. Structuring and smurfing — the behaviour people use to avoid these thresholds
• F. Customer risk and designations — lower thresholds for high-risk customers (F3)
• Tuning and calibration
• Rule library overview