POS INTELLIGENCE PLATFORM
Fraud Detection & Merchant Performance
LIVE
🔑
Optional: Anthropic API key for AI analysis
Get one at console.anthropic.com. Stored locally only.
Total transactions
0
Failed
0
declined / failed
Flagged (suspicious)
0
High risk
0
Unusual amounts
0
Approved volume
0
GHS
💰 High amount threshold Flag any transaction above GHS
Column filters — add as many as you need, all conditions are applied together (AND)
0 transactions
TimeBatchTerminal NameTerminal IDMerchant Amount (GHS)CardRiskFlags
Upload transaction data to begin analysis
📂
Drop CSV or Excel file here
Supports .csv · .xlsx · .xls — columns auto-detected · data stored persistently
— or —

Column mapping — auto-detected (adjust if needed)

STORED BATCHES
No batches uploaded yet
🧠
Merchant profiles are built automatically from all uploaded transaction history. The system learns each merchant's typical amount range, active hours, and usual terminals — and flags anything that deviates significantly.
Upload transaction data to build merchant profiles
Focus month Compare with
Filter by monthly sales GHS
🏆 Top performers
⚠ Lowest performers
Click a merchant to view details
Merchant
Select months to display
Month-by-month performance
Volume trend
Payment method breakdown
POS terminal breakdown
How fraud detection works
This system analyses every transaction against five detection rules and one statistical model. Each rule that fires on a transaction adds to its risk score. The more rules triggered, the higher the risk level assigned.
🎯 How risk levels are assigned

After all rules are checked, each transaction is given a risk level based on how many flags it triggered:

High 3 or more rules triggered, or the unusual amount flag fired alongside at least one other rule. These transactions need immediate attention.
Medium Exactly 2 rules triggered simultaneously. Worth reviewing before approving.
Low Only 1 rule triggered. Something is slightly unusual but not necessarily fraudulent. Monitor for patterns.
Clear No rules triggered. The transaction looks normal based on all checks.
Failed The transaction was declined or failed at the point of sale. Failed transactions are tracked separately and do not go through fraud scoring — they have their own tab for review.
💰 High amount Fixed threshold rule

What it checks: Whether the transaction amount exceeds the configured high amount threshold in a single sale. The current threshold is GHS 5,000 — you can change this directly on the Fraud Dashboard.

Why it matters: Large one-off transactions at a POS terminal are statistically uncommon and are a well-known pattern in card-present fraud. Stolen cards are often used to make a single large purchase quickly before being blocked.

How it fires: If the sale amount is above GHS 5,000 → the High Amount flag is raised.

Example
A GHS 12,000 sale at a grocery store that typically processes transactions between GHS 50–800 would trigger this flag.
💡 This threshold is fixed at GHS 5,000. It is separate from the statistical outlier check below, which is merchant-specific.
⚡ High velocity Card usage frequency rule

What it checks: How many times the same card has been used across any terminal within a 1-hour window, centred on the transaction being assessed.

Why it matters: A real cardholder rarely makes more than 2–3 purchases in an hour. If the same card appears 4 or more times within 60 minutes — across different merchants or terminals — it is a strong indicator the card details have been cloned and are being used simultaneously or in rapid succession.

How it fires: The system counts all transactions on the same card number within ±60 minutes of each transaction. If that count is 4 or more → the High Velocity flag is raised.

Example
Card ****4729 processes at Merchant A at 14:02, 14:18, 14:35, and 14:51. All four transactions are within 60 minutes of each other → all four are flagged for high velocity.
💡 The 1-hour window moves with each transaction — it is not a fixed clock hour. Each transaction is assessed independently against its own 60-minute window.
🌙 Off-hours Time-of-day rule

What it checks: Whether the transaction occurred between midnight (00:00) and 5:59 AM, or at 11:00 PM (23:00) or later.

Why it matters: Most legitimate POS terminals are operating during normal business hours. Transactions processed in the early hours of the morning are unusual for most merchant categories and are a common pattern in fraudulent use of compromised card details or terminal tampering.

How it fires: If the transaction hour is before 6:00 AM or is 11:00 PM or later → the Off-Hours flag is raised.

Example
A sale processed at 02:47 at a retail outlet that normally operates 8am–9pm → flagged as off-hours.
💡 Some merchants legitimately operate late (petrol stations, hospitals, 24-hour convenience). Use the Merchant Intel view to review a merchant's usual hour distribution before concluding this flag is suspicious.
📍 Location flag Geographic mismatch rule

What it checks: Whether the transaction's recorded location is inconsistent with the merchant's known operating locations based on transaction history.

Why it matters: A transaction appearing from an unexpected location — a city or region where a merchant has never processed before — can indicate terminal cloning, data replay attacks, or a compromised merchant account being used remotely.

How it fires: When data is uploaded, the system records all locations each merchant has previously processed from. If a new transaction arrives from a location not seen before for that merchant, and the location field is populated → the Location Flag is raised.

Example
Merchant "ShopRite Accra" has only ever processed from Accra locations. A transaction arrives tagged to "Kumasi Central" → flagged for location mismatch.
💡 This flag depends on the Location column being mapped during upload. If your file does not have a location/branch/city column, this rule will not fire.
🔮 Unusual amount Statistical baseline rule — how it works

What it checks: Whether a transaction amount is unusually large compared to what that specific merchant normally processes — not a fixed number, but relative to their own history.

How the baseline is built

Every time you upload data, the system reads all approved transactions for each merchant and learns their typical sale pattern. For each merchant it calculates:

  • Average sale: the mean amount across all their transactions
  • Typical spread: how much individual transactions vary from that average (standard deviation)
  • Normal range: the 10th to 90th percentile of their sale amounts — the band that covers 80% of their usual transactions

This profile is rebuilt every time new data is added, so the system learns continuously.

How a transaction gets flagged

When a transaction comes in, the system calculates how far its amount sits from that merchant's average, measured in "steps" of the merchant's typical spread. If the amount is more than 3 steps above the average, it is considered statistically unusual for that merchant and the flag is raised.

The system only flags amounts that are significantly higher than normal — it ignores unusually small amounts, since small transactions are rarely fraudulent.

Plain-English example
KFC Osu typically processes sales between GHS 30–300, with an average around GHS 85. A transaction comes in for GHS 4,200. That amount is so far above KFC's normal range that it would take more than 3 "steps" of spread to reach it from their average — so the system flags it as an unusually high amount for this merchant.

The same GHS 4,200 at a car dealership that regularly processes GHS 3,000–15,000 sales would not be flagged, because it sits comfortably within that merchant's normal range.
Minimum data requirement

This check requires at least 5 approved transactions for a merchant before a baseline can be established. Merchants with fewer than 5 transactions will not have this rule applied to them.

💡 This is the most powerful rule in the system because it is personalised to each merchant. A fixed threshold like "flag anything over GHS 5,000" would miss fraud at a high-value merchant while over-flagging at a low-value one. The statistical approach adapts automatically to each merchant's actual behaviour.
⚠ Why combinations matter most

Any single flag on its own may have an innocent explanation. The risk level rises significantly when multiple flags fire on the same transaction, because legitimate explanations become much harder to construct:

  • A large amount at an off-hours time → two flags → Medium risk
  • A large amount, off-hours, and a new location → three flags → High risk
  • An unusually high amount for the merchant plus any other flag → High risk — this combination is particularly significant because it means the transaction is abnormal both in absolute terms and relative to the specific merchant's history

When reviewing flagged transactions, always look at the full combination of flags and the transaction's context in the merchant's history (available in the drill-down panel when you click any transaction).