F. Customer risk and designations

Some customers need closer attention because of who they are, not what any single transaction looks like:

• Sanctioned persons and organisations, whom you may be legally barred from dealing with at all.
• Politically exposed persons (PEPs) — people with prominent public roles, and their relatives and close associates — who carry a higher risk of corruption and bribery.
• Customers your institution has rated high-risk.
• Counterparties you have decided never to deal with.

In SpeculaPro these facts are recorded as risk designations on customers and counterparties, and as lists. The rules in this category read them. See Risk designations and lists for how designations are set, evidenced and revoked.

Where designations come from

An authorised user sets a designation by hand, with a reason and evidence, or a reviewer confirms a screening match as a true match, which sets the same designation. The rules on this page work the same either way. In real-time decisions, your workspace’s screening policy also acts on sanctions matches without a rule.

Values here are examples

Thresholds on this page illustrate how the rules behave; see Tuning and calibration.

Rules in this category

ID	Rule	Mode	Status
F1	Any transaction by a designated sanctioned entity	RT	Ships (core, post-event; and as F1-RT in fraud, real-time)
F2	PEP transaction above threshold	RT/PE	Ships (core, post-event)
F3	High-risk customer: lower thresholds on all rules	—	Ships (core, post-event)
F4	Counterparty on tenant deny-list	RT	Ships for countries and merchant categories (fraud, real-time); named counterparties planned
F5	Transaction inconsistent with declared profile	PE/SCH	Ships (core, scheduled daily)

Blocking needs the decision API

F1 and F4 are meant to stop a payment before it happens. Their real-time versions in the fraud pack do that, but only for payments your system sends through a real-time decision. The post-event F1 in core still raises the AML alert for every transaction, decided or not.

---

F1 Any transaction by a sanctioned entity

Ships today in two forms

• core.sanctioned_party in the core pack runs post-event with severity critical: it raises an alert but cannot block the payment. Pack contents.
• fraud.sanctioned_party (F1-RT) in the fraud pack runs in real-time decisions and answers block. Pack contents.

Both check the customer and the counterparty for a current sanctioned designation. Run both: the real-time rule stops the payment, the post-event rule makes sure the AML alert exists.

What it looks for: any transaction at all involving a customer or counterparty with an active sanctioned designation. There is no threshold: the amount does not matter.

Example

• ✅ Fires: a customer designated sanctioned attempts to send GHS 50.
• ✅ Fires: any customer attempts to pay a counterparty designated sanctioned.

Parameters: none. The action is always to block or hold for review.

Mode and pack: post-event in core, real-time in fraud. Both ship today.

Do not suppress F1

Dealing with a sanctioned person can be a criminal offence for the institution. If an F1 hit is wrong, the fix is to review and, if justified, revoke the designation (with a reason, which is recorded) — not to suppress the rule. Escalate every F1 hit to your MLRO or compliance officer.

Data it needs: designations kept current, and counterparties identified well enough to be matched.

---

F2 PEP transaction above threshold

Ships today: core.pep_threshold in the core pack

Default threshold is GHS 10,000. Relatives and close associates (pep_rca) are always included. Exact defaults and logic: Pack contents.

What it looks for: transactions by a politically exposed person above a threshold. Being a PEP is not wrongdoing; it means larger flows deserve a documented look, in line with enhanced due diligence.

Example

With threshold_amount GHS 20,000 and include_relatives_associates on:

• ✅ Fires: a domestic PEP receives GHS 45,000 from a company.
• ✅ Fires: the spouse of a PEP (designated pep_rca) sends GHS 30,000.
• ❌ Does not fire: a PEP pays a GHS 900 utility bill.

Parameters

Parameter	Meaning	How to tune
threshold_amount	Amount above which PEP transactions are reviewed	Lower than general thresholds; follow your EDD policy
include_relatives_associates	Whether relatives and close associates (pep_rca) are included	Usually on

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

Routing PEP cases to level 2

Automatic routing by designation is planned through escalation policies. Until then, escalate a PEP case by hand when you open it. See Escalation and SLAs.

Data it needs: pep and pep_rca designations on customers; amount.

---

F3 High-risk customer: lower thresholds on all rules

Ships today: core.high_risk_customer in the core pack

Works differently from this description: it raises its own alert when a high-risk customer (rating high or unacceptable, or a high_risk designation) makes a transaction of at least threshold (default GHS 10,000). It does not lower other rules’ thresholds. Exact defaults and logic: Pack contents.

What it looks for: nothing on its own. F3 is a modifier: for customers rated high-risk, it multiplies the thresholds of other rules so they trigger earlier.

Example

With a multiplier of 0.5:

• A1 normally fires above GHS 50,000. For a high-risk customer it fires above GHS 25,000.
• C2 normally fires at 5× the customer’s usual value. For a high-risk customer, it fires at a lower multiple.

Parameters

Parameter	Meaning	How to tune
multiplier	Factor applied to other rules’ thresholds	0.5 halves them. Test in shadow — the effect is felt across every rule

Mode and pack: applies to whichever rules it modifies.

Data it needs: the customer’s risk rating (high) or a high_risk designation.

---

F4 Counterparty on tenant deny-list

Ships today in part: fraud.deny_listed_counterparty in the fraud pack

Real-time, answers block. Fires when the counterparty’s country is on your blocked_countries list, or the merchant category code is on your blocked_mcc list. It doesn’t check named counterparties (wallets, accounts, devices) yet. Until it does, flag a confirmed scam wallet with a custom designation, such as custom:confirmed_scam, and have a rule author build a real-time rule that blocks when the counterparty’s designations include it. Exact defaults and logic: Pack contents.

What it looks for: a transaction with a counterparty (account, wallet, device or identifier) on one of your deny-lists — for example accounts confirmed as fraud collection accounts.

Example

With blocked_countries holding a country your institution doesn’t allow payments to, and blocked_mcc holding 7995 (gambling):

• ✅ Fires (ships today): a customer tries to send GHS 700 to a counterparty in the blocked country.
• ✅ Fires (ships today): a card payment at a gambling merchant.
• 🕒 Planned: a customer tries to send GHS 700 to a wallet on a list of confirmed scam wallets.

Parameters

Parameter	Meaning	How to tune
blocked_countries, blocked_mcc	The lists the shipped rule checks. It has no other parameters	Keep separate lists for separate reasons, so you can see why something is blocked. Record why each entry was added

Mode and pack: real-time, fraud pack: countries and merchant categories ship today; named counterparties are planned.

List items can expire

Each item on a list can have an expiry date. Use it for temporary blocks — for example while a complaint is investigated — so lists do not fill up with stale entries.

Data it needs: today, counterparty_country or mcc on the transaction, and the blocked_countries or blocked_mcc list. Until a list exists with at least one current entry, the rule never fires.

---

F5 Transaction inconsistent with declared profile

Ships today: core.declared_profile in the core pack

Scheduled, every day at 04:00. Alerts about the customer. Watches individuals by default. Fires when a customer’s turnover over the last 30 days, scaled to a month, is more than 3 times what they declared, or, with nothing declared, more than the ceiling set for their occupation, and is at least GHS 5,000. Exact defaults and logic: Pack contents.

What it looks for: a customer moving far more than they told you they would when they opened the account, or far more than their occupation makes plausible.

Example

With the defaults (period_days 30, multiplier 3, min_volume 5,000, money in and out counted):

• ✅ Fires: a teacher who declared GHS 3,000 a month moves GHS 14,000 through the account in 30 days: more than 3 × GHS 3,000.
• ✅ Fires: a student with no declared volume moves GHS 12,000 in 30 days: more than 3 × the GHS 3,000 ceiling set for student.
• ❌ Does not fire: GHS 5,000 in a busy month for the teacher (under 3 ×).
• ❌ Does not fire: a customer with no declared volume and an occupation that isn’t in the ceilings list: there is nothing to compare with.

Parameters

Parameter	Meaning	How to tune
period_days	The period looked at, in days (7 to 92). Turnover is scaled to 30 days	30 for a month; longer smooths out one-off months
multiplier	How many times the declared monthly volume counts as too much (1 to 100)	2–5 are typical values to test
min_volume	Turnover over the period at or above (base currency)	Stops small accounts alerting on tiny declarations
direction	Count money in, out, or any (both)	any catches money passing through
customer_types	individual, business; empty means all	Businesses are covered by I1
segments	Only these segments; empty means all
occupation_caps	Expected monthly turnover by occupation, used when no volume was declared (base currency)	The defaults are examples: student 3,000, unemployed 2,000, pensioner 5,000, artisan 15,000, civil servant 20,000. Set your own

Occupations are matched ignoring case and surrounding spaces, so Student and student both match student. A volume declared in another currency is ignored and the occupation ceiling is used instead.

The occupation ceilings need your institution’s sign-off

The default ceilings are illustrations, not figures from the Bank of Ghana or the FIC. Agree real ones with your MLRO, based on your customer risk assessment, before relying on this rule.

Mode and pack: scheduled, every day at 04:00 (daily 04:00), in core 1.1.0. See Scheduled rules. Once it has flagged a customer, it doesn’t flag them again for the length of the period.

False positives: declarations that were never updated. When an analyst confirms new legitimate income, update the customer’s declared volume so the rule stops firing.

Data it needs: completed transactions with a customer, and on the customer: declared_monthly_volume_minor with declared_currency, or occupation.

Related

• Risk designations and lists
• E. Geography and high-risk exposure
• Tuning and calibration — more on the F3 multiplier
• Alerts, cases and escalation