Fraud prevention platformsمنصات مكافحة الاحتيال Fraud

Fraud is somebody paying with money that is not theirs, or the owner of the money being tricked into paying it themselves. That gap between the two shapes is what makes it hard to catch.

A legitimate payment and a manipulated one can look identical in a system record. Fraud platforms sell the signal, the decision, and the intervention before money leaves.

What is the difference between fraud and money laundering?

People conflate them because both are crimes and both are watched by similar-looking systems. The difference is fundamental, and it decides everything about how the product is built.

Fraud means your money is gone. Someone stole your card or tricked you into sending it. The victim is you, or the merchant, or the bank.

Money laundering means someone else's money passes through you. A criminal uses your system to make their money look clean. You lose no riyal. You lose your licence if it keeps happening.

Everything else follows from that difference.

Fraud has a victim who complains the same day, so success is measured in speed: stop the movement before the money leaves. Laundering has nobody to complain, may run for months unnoticed, and success is measured by the quality of the report rather than its speed.

Fraud is a direct loss in your books, so you weigh what you lose against what you prevent and accept a sensible loss rate, because excessive strictness drives customers away. Laundering does not compute that way, because the loss is not money but a penalty that can close the business.

The two systems look alike on screen. Their goals and their metrics are nothing alike.

Begin with who controls the account

Account takeover (الاستيلاء على الحساب) occurs when a criminal gains access to a genuine customer's account. They may steal a password through phishing, take over a phone number, or reuse a captured session. The name, account, and balance remain real, but the person issuing instructions has changed.

Risk often appears before the transfer. A new device signs in from a distant location, changes the password and phone number, then adds a beneficiary and sends the maximum amount. No single signal proves theft, but the sequence departs from the customer's normal journey.

Protection begins at login. Systems can block leaked passwords and rapid attempts, recognise devices, and notify customers about sensitive changes. Account recovery needs stronger protection than ordinary sign-in because an attacker may bypass technical controls by manipulating support staff.

An old session should not remain fully trusted after a high-risk event. A phone-number or device change may temporarily restrict sensitive actions. A new beneficiary may trigger stronger evidence before payment. That pause gives the customer time to notice an alert.

Card testing is a volume attack

Card testing means trying large numbers of stolen card details to learn which remain usable. The attacker does not begin with an expensive purchase. Small payments at a weak merchant or donation page validate cards for larger fraud later.

Each attempt can appear harmless. The amount may be SAR 5, the merchant genuine, and declines common in commerce. Thousands of attempts sharing a device, network, or linked accounts reveal the attack. Monitoring therefore needs a view wider than one card.

A merchant can limit attempt speed and the number of cards per device. A payment provider can see a repeated pattern across merchants. An issuer can request stronger authentication or decline according to risk. Each party sees a different part, and timely signals improve the shared defence.

Blocking every small payment is not the answer. Customers buy coffee and pay legitimate low-value subscriptions. A decision should combine value with velocity, card diversity, device reputation, and authentication result. A checkout page must not become a free testing tool for criminal lists.

A mule account (حساب التمرير) belongs to a real person

A mule account moves criminal proceeds for someone other than its holder. A student may rent an account for SAR 200. A job seeker may answer an advertisement asking them to receive and forward payments. A criminal may recruit people to open accounts with their genuine identities.

The holder does not always look like a technical attacker. They pass identity checks in their own name and use their own phone. Behaviour exposes a role inconsistent with the profile: transfers arrive from many victims, leave quickly, and only a small commission remains.

Detection should examine networks as well as individual accounts. Accounts may share a device, address, beneficiary, or timing pattern. Twenty accounts may feed one wallet before funds leave the country. Links turn scattered transactions into an organised operation.

Closing an emptied account is not enough. The team needs to prevent connected replacements, examine recruitment routes, and file required reports. It should also distinguish people who were deceived from those participating knowingly.

When the customer authorises the loss

An authorised push payment scam, or APP scam, convinces the customer to send money. A criminal may impersonate a bank employee and claim the account is in danger. They may replace a regular supplier's invoice or build a long relationship before asking for a transfer.

Authentication works as designed in these cases. The real customer uses their device, enters the code, and confirms the beneficiary. The system must ask more than whether the person was authorised. It needs context about the destination, behavioural change, and pressure on the customer.

A product can insert a meaningful pause. It can display the beneficiary and value clearly, warn about a name mismatch where that service exists, and tailor a warning to the stated payment purpose. A generic message shown every time only teaches customers where the dismiss button sits.

Human staff can hear signals that rules cannot see. A customer may say that an officer told them to keep a call open. They may refuse to explain a transfer of savings to a new personal account because the caller demanded secrecy. Staff need training and a fast route to pause and review the payment.

Blaming customers is not a substitute for better controls. Criminals deliberately exploit fear, trust, and urgency. Providers know whether the beneficiary is new, the device changed, the transfer is unusually fast, or the receiving account has attracted earlier complaints. That information should be used before finality.

The decision sits between two losses

Stopping a legitimate payment is a false positive (الإنذار الكاذب). It has a real cost. A traveller cannot pay a hotel, a shop misses a supplier deadline, or a customer loses confidence after five verification requests.

Fraud loss cannot be optimised alone. A rule that declines every transaction prevents fraud and destroys the product. Approval cannot be optimised alone either, because allowing everything increases loss. Fraud value and legitimate transactions stopped must be measured together.

Useful measurement includes loss per thousand transactions, affected customers, alert precision, resolution time, and abandonment. A transaction paused and later released differs from one that remains declined. The first creates friction; the second may lose the customer entirely.

The cost of error also depends on context. Extra proof for a new beneficiary is less harmful than blocking an entire card at a familiar shop. Delaying a savings transfer to a new destination may be more defensible than delaying a known monthly salary payment. Policy should reflect both risk and customer effect.

Step-up authentication (التوثيق التصاعدي) at the risky moment

Step-up authentication requests stronger proof when risk rises. It does not make every action difficult. A familiar customer follows the ordinary path until a device, beneficiary, amount, or behaviour change justifies another step.

The step might be approval inside a trusted app displaying transaction details, a biometric check, or human contact for a large case. Sending a code to a phone number changed one minute earlier is weak because the attacker may control that same channel. The evidence should be independent of the risk signal where possible.

Failure needs a defined outcome. If the customer cannot complete the step, the product must not repeat it forever or quietly execute the transfer. It pauses the request, informs the customer, and offers secure recovery. Recording the reason and result supports later learning.

Instant payment compresses the decision

Instant rails leave little intervention time. Once funds are available to the recipient, they may move through another account in seconds. Later recovery calls and freezes can help in some cases, but they do not restore every payment. Prevention before execution is therefore the only dependable control.

Device, behaviour, beneficiary, and velocity signals must reach the decision before the final instruction. A model returning a score five minutes later is too late. The control needs low latency, explicit limits, and an escalation option. A risk-service outage must not silently turn into approval for everything.

Fraud rings do not remain fixed. They probe thresholds, learn from declines, and move to a weaker channel within days. Complaints, recoveries, and investigations must feed models and rules. Changes should be tested against both fraud loss and false positives before broad release.

Monitoring becomes an operating capability when it changes the product in time. A stolen session is blocked, card testing is throttled, a mule network becomes visible, and a deceived customer receives a meaningful pause. No single model delivers that result. It comes from a loop connecting signal, decision, intervention, and outcome.