Payment Fraud Prevention

For a card payment, the fraud decision is taken before you capture the money. You send the transaction on the decision call with subjectType: "card_payment", and get one of four decisions back:

Decision	What you should do
`allow`	Proceed with the payment
`force_3d`	Step the transaction up to 3DS — do not let it through without it
`review`	Send to human review; do not capture, or hold
`block`	Decline

force_3d lets you apply friction selectively. Low-risk transactions pass without 3DS, protecting conversion; only risky ones get stepped up. You trigger 3DS with your own provider — we make the decision, your payment integration runs the flow.

The fields you send

The payment object's fields and the risk each one feeds:

Field	Feeds
`amount`	amount thresholds, velocity value, flat-amount clustering
`currency`	multi-currency thresholds
`is3D`	authentication posture — you can write separate rules for non-3DS transactions
`country` · `cardCountry`	geography and card-country mismatch
`installmentCount`	instalment anomalies
`method`	payment method
`id`	card reference — send a PCI-compliant token or fingerprint, never the PAN

All amounts are minor-unit integers (250000 = ₺2,500.00). Full field contract: Decision API.

Card testing

Low-value bursts used to find which cards on a stolen list are still live. Two templates target this pattern directly:

Template	What it measures
`tcmb_3_1_2_6_card_txn_velocity_2h`	Transaction count on the same card within 2 hours
`tcmb_3_1_2_14_card_inter_arrival`	Gap between consecutive transactions on the same card

Add tcmb_3_1_2_10_otp_fail_merchant_1h (OTP failures per merchant in one hour) and brute-force behaviour is caught without touching an amount threshold at all.

Merchant risk indicators

If you are a PSP scoring your own sub-merchants, the TCMB Risk Management Guide section 3.1.2 templates ship ready to use:

Template	Indicator
`tcmb_3_1_2_1_own_turnover_4x`	Volume exceeding 4× the merchant's own turnover
`tcmb_3_1_2_1_sector_turnover`	Deviation from the sector average
`tcmb_3_1_2_9a/9b/9c_new_merchant_volume_m1/m2/m3`	Volume spike in a new merchant's first three months
`tcmb_3_1_2_3_weekend_ratio_monthly`	Weekend transaction ratio
`tcmb_3_1_2_4_night_ratio_monthly`	Night-time transaction ratio
`tcmb_3_1_2_5_flat_ratio_monthly`	Flat (round) amount ratio
`tcmb_3_1_2_domain_age_lt_90`	Domain younger than 90 days
`tcmb_3_1_2_iban_change_3_in_90d`	Three IBAN changes in 90 days
`tcmb_3_1_2_21_backurl_host_mismatch`	Return-URL host mismatch
`tcmb_3_1_2_shell_company_ubo_firstpass`	Shell company / UBO first-pass screen

Each returns with the TCMB reason-code prefix, so a rule that fires traces from reasonCodes back to the regulatory clause.

Behavioural signals

Whether the card number was pasted or typed, time spent in the form, tab switching — all are signals you can write rules against. You do the collecting: measure it in your own interface and send it in the decision call's telemetry field. Field names and the silent-drop rule: Behavioural Risk Signals.

What we do not do

⚠️

There is no chargeback prediction field. The response does not return chargebackRisk or chargebackFactors. If you want to use dispute history, bring it in from your own data with the database-lookup node.

The response shape is the standard one — decision, score, reasonCodes, flowPath, explainability. There is no { action, recommendation, fraud: { status } } envelope.
There is no packaged account-takeover model; you compose new-device, unusual-geography and OTP-failure signals into rules yourself.

Decision API — field contract, authentication, request and response examples
Transaction Monitoring — the counting nodes and all 53 templates
Flows and Resolution — the scope you publish the flow under

Overview Behavioural Risk Signals