DEV Community: Amir Shachar

First-Time Payees, Payouts, and Why Clean Transactions Still Turn Into Fraud Losses

Amir Shachar — Wed, 01 Apr 2026 07:10:24 +0000

Originally published at Riskernel.

Some of the worst fraud losses do not look obviously bad at the transaction level.

The amount may look normal. The device may be familiar. The customer may even pass the basic checks. Then the money leaves anyway, and the loss shows up later.

That happens because many fraud systems still score the event too narrowly. The real weakness is often in the setup around the event: a first-time payee, a change in payout path, an unusual sequence before release of funds, or a contextual signal that never made it into the decision.

The transaction is not always where the risk lives

Event-centric scoring works well when the event itself carries the anomaly. But some fraud patterns are cleaner than that. The transaction can look almost ordinary while the surrounding setup tells a very different story.

That is especially true in payouts, account changes, and certain APP-style flows where the harmful part is not “this payment is weird” but “this setup makes the payment dangerous.”

Why first-time payees deserve separate attention

A first-time payee is not automatically fraud. But it is often a context shift that deserves more weight than teams give it.

It changes the trust assumptions around the transaction.
It is often part of a sequence, not a standalone event.
When combined with timing, device, or behavior changes, it becomes much more informative.

The mistake is treating it as just another feature instead of a structural change in exposure.

New payee added. Payout requested soon after. Amount is not extreme. Device looks mostly familiar. The transaction alone may score as clean. The setup around it does not.

Payouts are not just purchases in reverse

Teams often reuse too much logic between payment approval and payout approval. That is a mistake.

Payouts deserve separate thinking because the fraud incentives, timing pressure, and loss mechanics are different. By the time the payout event arrives, the decision window is tighter and the operational cost of being wrong is often higher.

What the rules engine usually misses

Rules are still useful, but this is where they often become blunt. A rule can spot “new payee plus large amount” or “payout after account change.” It is less good at combining weaker contextual shifts that only become meaningful together.

That is also why per-decision explanations matter. If the system can show that the model relied on a first-time payee, timing shift, and payout-path change together, the analyst has something real to work with. If it only emits a generic risk score, the queue gets slower and the pattern stays hard to debug. That operational side is covered here: SHAP Explainability for Fraud Ops.

One concrete loss pattern

A customer account appears healthy. A new payee is introduced. The payout request lands shortly after, and nothing about the raw amount looks shocking. A simple transaction-level view may let it pass.

The problem is that the suspicious part was distributed across the setup, not concentrated in one obvious event. If your system only scores the event in isolation, you are asking it to miss exactly the kind of loss you care about.

What buyers should evaluate in vendor demos

If you are comparing fraud vendors, ask them to walk through a setup-sensitive case, not just a cartoonishly bad purchase. Ask how the system handles first-time payees, payout timing, and context shifts around release of funds.

Then ask whether the decision arrives fast enough for the real approval path. That is where the latency article matters: Real-Time Fraud Scoring Latency: What 47ms Actually Means. And if you want to validate the whole thing on your own traffic, start with Shadow Testing a Fraud Vendor Before You Touch Production.

The practical standard

Good fraud systems do not just ask whether the transaction looks suspicious. They ask whether the setup around the transaction changed the exposure in a way the business should care about before money moves.

That is a better standard for payouts, first-time payees, and the kinds of clean-looking losses that still hurt teams every day.

Note

Canonical version: https://riskernel.com/blog/first-time-payees-payout-fraud.html

Next read: SHAP Explainability for Fraud Ops

Handling Extreme Class Imbalance in Fraud Detection

Amir Shachar — Wed, 01 Apr 2026 07:09:27 +0000

Originally published at Riskernel.

Fraud is one of the easiest machine learning problems to misunderstand because the target is so rare.

In many portfolios, fraud is well below one percent of total events. That means a model can look excellent in offline evaluation while still creating a terrible operational outcome once it meets production traffic.

If you are evaluating a fraud vendor or building your own stack, the first thing to understand is that this is not a standard classification problem. It is a rare-event decisioning problem with operational consequences.

Why the base rate changes everything

When fraud is extremely rare, “accuracy” becomes almost meaningless. Even AUC can look strong while the operating threshold behaves badly in the live queue.

The real question is not “can the model separate classes in a notebook?” It is “can the model catch enough fraud at a threshold that does not drown the team in false positives?”

Why good offline metrics can still mislead you

A vendor can show an impressive offline result and still fail your production test. That usually happens because the evaluation is too abstracted from the actual decision environment.

The fraud rate in the evaluation set is higher than the real portfolio.
The metrics focus on global ranking quality, not threshold behavior.
The review-cost side of false positives is treated as secondary.
The result is measured before the model meets missing signals, noisy enrichment, and shifting attack patterns.
What happens at the actual operating threshold?
How do precision and recall behave on the live base rate?
How many extra cases hit the review queue for each incremental fraud catch?
How is performance monitored after launch as the fraud mix shifts?

Where oversampling starts to lie

Techniques like oversampling and synthetic minority generation can be useful during model development, but they are easy to over-trust.

The risk is not that these methods are always wrong. The risk is that they create a neat offline world that smooths over the messiness of production. Fraud does not arrive as clean synthetic clusters. It arrives in bursts, edge cases, and changing patterns that interact with the rest of your decision system.

One concrete failure mode

A team evaluates a model on a rebalanced dataset and gets a result that looks excellent. Then they move toward production and discover the threshold that looked fine offline now routes too many cases to manual review.

The model is not useless. The evaluation was incomplete. The hidden problem is not raw ranking quality. It is that the model was never judged against the real review-cost tradeoff.

This is why buyer evaluations often go wrong

When buyers compare vendors, they often hear broad claims about AI quality, risk intelligence, or detection performance. Without threshold-level evaluation, those claims stay too vague to be useful.

That is why a practical buying process should combine the full API checklist in Fraud Detection API: What to Look For in 2026 with a real shadow run on your own traffic. If you want the evaluation workflow itself, start here: Shadow Testing a Fraud Vendor Before You Touch Production.

Operationally, false positives are part of the model

Fraud teams often talk about the model as if it stops at the score. It does not. The model continues into the queue, the analyst experience, the customer support burden, and the approval rules that sit around it.

That is also why explainability matters. If the false-positive cluster is invisible, fixing it takes longer. If the analyst can see what drove the decision, the team can debug faster. That operational side is covered in SHAP Explainability for Fraud Ops.

The practical standard

For fraud, the right standard is not one pretty model metric. It is a model that still behaves well when the fraud rate is tiny, the cost of review is real, and the threshold has to survive production conditions.

That is a harder bar, but it is the one that actually matters.

Note

Canonical version: https://riskernel.com/blog/extreme-class-imbalance-fraud-detection.html

Next read: First-Time Payees, Payouts, and Why Clean Transactions Still Turn Into Fraud Losses

Shadow Testing a Fraud Vendor Before You Touch Production

Amir Shachar — Wed, 01 Apr 2026 07:08:07 +0000

Originally published at Riskernel.

The fastest way to make a bad fraud buying decision is to trust a polished demo.

Every vendor can show a clean dashboard, a few good examples, and a latency number that looks comfortable. None of that tells you how the system behaves on your own traffic, inside your own approval flow, with your own mix of customers, missing signals, payout patterns, and operational constraints.

If you are evaluating a fraud vendor seriously, the right next step is not production. It is a shadow test.

What a shadow test actually is

A shadow test means the vendor scores your real traffic in parallel without changing production behavior. Your current stack still makes the live decision. The candidate system watches the same events and produces its own outputs so you can compare them safely.

That matters because buying a fraud product is not only about model quality. It is about whether the score distribution, explanations, latency, and queue impact make sense in your operating model.

Why feature checklists and demos are not enough

The weak part of most evaluations is that teams compare capabilities instead of behavior. “Uses AI,” “has device intelligence,” or “supports rules plus ML” are not useful discriminators once the vendor is inside the shortlist.

The practical questions are different:

Does the system stay fast enough when traffic is real?
Do the explanations help analysts move faster or just sound impressive?
Do false positives cluster in ways that create extra review work?
Do the scores line up with your actual fraud patterns, not the vendor's favorite demo set?

What to compare during the test

P50, P95, and P99 latency.
Score distribution by flow, not just one global average.
Top explanations or reasons on flagged cases.
Precision and false-positive patterns at candidate thresholds.
Analyst feedback on whether the outputs are usable.

If you skip any of those, you usually end up learning too late that the “good” pilot was never operationally good in the first place. For the broader evaluation checklist, start with Fraud Detection API: What to Look For in 2026.

How long it should run

Long enough to capture real variability. If you run a shadow test for a day or two, you mostly learn how the system behaves on a clean slice of traffic. That is not enough.

You want enough volume to see quiet periods, peak periods, incomplete enrichment, weird edge cases, and at least a few analyst-reviewed outcomes. In most teams, that means at least one to two weeks of real traffic.

One concrete failure mode

A vendor can look excellent in the first meeting: strong average latency, modern UI, and plausible reasons on a few example cases.

Then the shadow run starts. On payout traffic, the scores compress into a narrow range, the reasons are generic, and the tail latency becomes erratic whenever one enrichment provider slows down. None of that was visible in the demo. All of it matters in production.

If you want the latency part of that problem in isolation, read Real-Time Fraud Scoring Latency: What 47ms Actually Means. If you want to know what analysts should actually see, the SHAP article goes deeper: SHAP Explainability for Fraud Ops.

Red flags that should kill the pilot

The vendor avoids showing score distributions on your own traffic.
The reasons behind decisions are too generic to be operationally useful.
The system performs well only after heavy threshold tuning that hides weak base behavior.
Latency is framed only as an average and the tail is ignored.
Ops feedback is treated as secondary to offline model metrics.

What a good outcome looks like

A good shadow test ends with something simple: you understand how the new system behaves, what tradeoffs it introduces, and what production changes it would justify.

That is a much higher standard than “the demo looked good,” but it is the right one. Fraud infrastructure should earn trust on your traffic before it touches your approvals.

Note

Canonical version: https://riskernel.com/blog/shadow-testing-fraud-vendor.html

Next read: Handling Extreme Class Imbalance in Fraud Detection

Real-Time Fraud Scoring Latency: What 47ms Actually Means

Amir Shachar — Wed, 01 Apr 2026 07:06:40 +0000

Originally published at Riskernel.

Fraud vendors love to say they are fast. The problem is that “fast” usually means one cherry-picked number with no context.

If you are evaluating real-time fraud scoring for checkout, instant payments, payout approval, or account takeover flows, the only latency number that matters is the one your customer actually feels when the system is under load.

That is why “47ms” is useful only if you understand what sits behind it, and why averages by themselves are usually the wrong way to compare vendors.

Average latency is the easiest number to game

A product demo can produce a beautiful average. Production traffic usually does not.

P50 tells you what the middle of the distribution looks like.
P95 tells you what happens when the system is a bit stressed.
P99 tells you whether the tail is ugly enough to affect real users and downstream systems.

A vendor can still claim “sub-100ms average” while giving you a P99 that spikes into the high hundreds. That may be fine for a batch workflow. It is not fine for a hot path.

Why tail latency is the real product metric

In fraud, the decision rarely happens alone. It sits inside a longer chain: device signals, enrichment calls, policy logic, auth windows, orchestration, and the user waiting on the other side.

Once the tail gets bad, every other service has less room to breathe. Review queues start to absorb more borderline cases, fallback rules become more aggressive, and the user experiences friction that has nothing to do with model quality.

Fast enough depends on the flow

Not every workflow needs the same latency budget.

Card authorization and instant bank transfers need tight tails.
Payout approval has slightly more room, but delays still affect conversion and support load.
Manual review routing can tolerate slower decisions, but only if the output is much richer.

The right question is not “is this system fast?” It is “is this system fast enough for our exact flow when traffic is real, inputs are messy, and dependencies are imperfect?”

What to ask a vendor besides one number

If you want an honest answer, ask for these things together:

P50, P95, and P99 latency on production traffic.
Whether enrichment calls are included in the published number.
What happens when one upstream provider times out.
How the system degrades when signals are partial or missing.
Whether you can test latency in a shadow run against your own traffic shape.

If the answer stays vague, the number is usually marketing, not engineering.

Latency and explainability are connected

Teams often compare speed and explainability as if they trade off automatically. Sometimes they do. Often the real issue is bad product architecture, not physics.

A fast score that no one can trust creates queue work. A beautiful explanation that arrives too late breaks the flow. The useful system is the one that gives you both inside the budget the business can actually support.

If you are evaluating the full stack, the broader checklist is in Fraud Detection API: What to Look For in 2026. If you care about what the ops team sees after the decision lands, read SHAP Explainability for Fraud Ops.

The practical standard

A median of 47ms is useful because it leaves room for the rest of the transaction path. But it only matters if the tail stays controlled and the system keeps giving usable decisions when the environment is imperfect.

That is the bar teams should use when they compare fraud vendors: not one pretty number, but a distribution, under real conditions, with enough context to trust it.

Note

Canonical version: https://riskernel.com/blog/real-time-fraud-scoring-latency.html

Next read: Fraud Detection API: What to Look For in 2026

SHAP Explainability for Fraud Ops: What Analysts Actually Need

Amir Shachar — Tue, 31 Mar 2026 15:03:55 +0000

Originally published at Riskernel.

When a fraud vendor says “explainable AI,” the fastest way to test the claim is simple: ask to see one blocked payment.

Not a dashboard. Not a portfolio-level feature importance chart. One decision that an analyst has to review right now.

That is where most explainability stories fall apart. A global chart may tell you that transaction amount matters across the portfolio. It does not tell the analyst handling case #47,291 why this payment was blocked and whether the decision looks reasonable.

What useful explainability looks like

A useful fraud review screen shows the main reasons behind a specific score, in plain terms, for that specific transaction.

This transaction scored 0.87
first-time payee: +0.31
velocity spike in the last hour: +0.24
device fingerprint mismatch: +0.18
geolocation anomaly: +0.14

That is the practical value of per-decision feature attribution. SHAP is one way to do it well. The analyst no longer has to reverse-engineer the model from a black-box score.

Why portfolio-level feature importance is not enough

Portfolio-wide summaries answer a different question. They are useful for model development, not for ops execution.

They tell you what mattered on average, not what mattered on this case.
They do not help when a customer calls support about one blocked payout.
They do not make false-positive clusters obvious at the queue level.

Fraud operations need explanations that travel with the decision, not a report someone saw three weeks ago.

Where this changes the day-to-day work

The first change is review speed. Analysts stop guessing. They can see what the model relied on most, make a faster judgment, and move to the next case.

The second change is feedback quality. A black-box workflow usually produces vague complaints like “the model feels too aggressive.” A per-decision workflow produces something actionable: “we are over-weighting first-time payees for established customers with stable device history.”

The third change is trust. Product, risk, support, and compliance all work better when the answer is more specific than “the system said so.”

Explainability also helps catch drift

Drift monitoring usually starts with feature distributions, calibration, and loss metrics. That is right, but it is not the whole picture.

If the reasons behind decisions start shifting in a systematic way over a few months, that can be an early warning that something changed in the event stream, enrichment quality, or attack pattern. The point is not that SHAP replaces the rest of monitoring. It gives you one more operational lens that teams can actually read.

The real question to ask any vendor

If an analyst opens a case in your stack today, can they see the top reasons behind the score without calling data science?

If the answer is no, the model may still be smart, but the operating model is weak. For most teams, that gap matters more than another point of offline model performance.

If you are evaluating vendors more broadly, start with the full API checklist in Fraud Detection API: What to Look For in 2026, then compare how each system handles explainability in practice.

Note

Canonical version: https://riskernel.com/blog/shap-explainability-fraud-ops.html

Next read: Fraud Detection API: What to Look For in 2026

Fraud Detection API: What to Look For in 2026

Amir Shachar — Tue, 31 Mar 2026 15:02:51 +0000

Originally published at Riskernel.

Most fraud API evaluations go wrong for the same reason: teams compare feature lists instead of production behavior.

A vendor says it uses AI, supports real-time scoring, and integrates quickly. That sounds fine until you try to run it on live payment traffic and discover the score is hard to interpret, the latency spikes when volume jumps, or the ops team still cannot tell why a transaction was blocked.

If you are buying a fraud detection API in 2026, these are the questions worth asking before you start a pilot.

1. Can it decide fast enough for your flow?

Latency is not a vanity metric. It changes checkout friction, approval rates, and how much time you have left for downstream steps.

Ask for P95 and P99 latency, not just average response time.
Ask whether the vendor measures latency in production traffic or demo traffic.
Ask what happens when enrichment providers time out or return partial data.

If your use case is card authorization, instant transfers, or payout approval, a slow tail will hurt more than a nice average helps.

2. Can analysts see what the model relied on most?

A raw score is not enough. The ops question is simple: when a case lands in a queue, can someone understand it quickly enough to act?

A useful interface shows the top drivers behind a decision, not just a confidence number. If the analyst sees only “0.91 high risk,” review speed will stay slow and false-positive patterns will stay hidden.

Explainability also matters beyond the queue. It gives risk leaders a way to debug drift, justify policy changes, and explain outcomes to internal stakeholders. If you want the operational version of that problem, this SHAP guide for fraud ops goes deeper.

3. How does it behave on heavily imbalanced data?

Fraud is rare. That sounds obvious, but it still breaks a lot of vendor claims. A model can look accurate on paper while missing the cases that matter or flooding the team with false positives.

Ask what fraud rates the model was trained on.
Ask how the vendor measures precision and recall at the operating threshold, not just offline AUC.
Ask how performance is monitored after launch as fraud patterns shift.

If the answer stays high-level, that is usually a warning sign.

4. What does integration actually require?

“Easy integration” can mean anything from one REST endpoint to a months-long project with schema work, workflow tuning, analyst training, and data mapping across multiple systems.

The practical questions are these:

How many endpoints do you need to call in the hot path?
What minimum payload is required for a useful score?
Can you launch with your current event stream, or do you need a data project first?
What happens when signals are missing?

Good API-first products let you start narrow and expand. Bad ones front-load the entire project.

5. Will they let you shadow test before you commit?

You should not have to trust a slide deck. A serious vendor should let you run in parallel, inspect decisions, and compare performance against your current setup before you change production behavior.

That shadow phase is where most evaluation mistakes become obvious. You learn whether the model is fast enough, whether the reasons are usable, and whether the score distribution makes operational sense for your portfolio.

6. Does the product fit your operating model?

Some teams need a platform with queues, workflows, and case management. Others just need a clean scoring API they can plug into an existing system.

If you are a fintech with a small engineering team, buying a full enterprise platform when you only need fast scoring is usually how you end up overpaying for complexity.

If you are in that camp, the more relevant comparison is often not “best fraud vendor overall” but “best API-first tool for our flow.” That is also why buyers often start with a focused comparison like this Actimize alternatives breakdown instead of a general market map.

A simple evaluation checklist

Demand P95 and P99 latency.
Review one real analyst decision screen.
Ask how the model handles rare-event imbalance.
Run a shadow test before any go-live decision.
Match the product shape to your actual operating model.

Note

Canonical version: https://riskernel.com/blog/fraud-detection-api-guide.html

Next read: NICE Actimize Alternatives for Fintechs

NICE Actimize Alternatives for Fintechs: 2026 Comparison

Amir Shachar — Tue, 31 Mar 2026 15:01:46 +0000

Originally published at Riskernel.

NICE Actimize is the default answer when enterprise banks need fraud detection. It's comprehensive, battle-tested, and deployed at most of the world's largest financial institutions.

It's also expensive, slow to implement, and architecturally heavy for fintechs that need to move fast. If you're a payment processor, neobank, or lending platform with 50-500 employees, you're probably paying for capabilities you don't need and waiting months for an integration that should take days.

I spent four years at NICE Actimize building fraud detection models, including systems for Bank of America. I know the platform well -- both what it does right and where it creates friction for smaller, faster-moving companies. This comparison is based on that experience plus what I've seen in the market since.

Why Companies Look for Alternatives

Three recurring pain points drive the search:

Cost. Enterprise licenses start at $100K/year and scale quickly from there. For a Series A fintech processing moderate transaction volume, that's a significant chunk of runway allocated to a single vendor.
Implementation time. A typical Actimize deployment takes 3-6 months minimum. You often need Actimize-certified consultants to configure the system, which adds both cost and calendar time.
Complexity. Actimize is a platform, not an API. It comes with dashboards, workflow engines, case management, and reporting tools. If you need real-time transaction scoring and your team is 3 engineers, that's a lot of surface area to manage.

The Alternative Landscape in 2026

The market has split into roughly three tiers: enterprise platforms, startup-friendly API-first vendors, and specialized niche players.

Enterprise Platforms

Feedzai is the closest direct competitor to Actimize. AI-first architecture, strong in banking and payments. More modern than Actimize under the hood, but still enterprise-priced and enterprise-complex. If you're replacing Actimize and you're a large bank, Feedzai is the main alternative. If you're a fintech looking for something lighter, you'll hit similar friction.

SAS Fraud Management is the other legacy player. Strong analytics capabilities, but the implementation model is similar to Actimize -- heavy, consultant-driven, measured in months.

Startup-Friendly API-First

SEON focuses on digital footprint enrichment and device intelligence. Strong for e-commerce and online lending where you need to assess the person behind the transaction. Pricing starts around $600/month, which is a different universe from Actimize. The trade-off: SEON is enrichment-heavy but lighter on real-time ML scoring.

Sardine was founded by the ex-Coinbase fraud team. Strong on device intelligence and behavioral biometrics. Good fit for fintech and crypto companies. They've raised significant funding and are building a broader platform, but the core strength is still behavioral signals.

Unit21 gives you more flexibility to build custom rules and models on top of their risk infrastructure. Good choice if you have in-house fraud expertise and want control over your decisioning logic rather than a black-box score.

Niche Players

Alloy sits at the intersection of identity verification and fraud decisioning. Not a pure fraud scoring play, but it overlaps with the KYC/onboarding fraud use case. Strong for identity-centric fraud (synthetic identity, account takeover at onboarding).

Kount (Equifax) focuses on e-commerce fraud. Acquired by Equifax, which gives it access to credit bureau data. Good for card-not-present fraud in retail. Less relevant for payment processors or lending platforms.

What to Actually Evaluate

When comparing alternatives, the feature matrices and pricing pages only tell part of the story. Here's what actually matters in production:

1. Latency

If you need real-time transaction decisioning (card transactions, instant payments, push-to-card), latency is a product requirement. Anything over 200ms adds noticeable friction. Ask for P99 latency, not average. A vendor claiming "sub-100ms average" might have a P99 of 800ms, which means 1 in 100 of your customers experiences a nearly one-second delay.

2. Explainability

Most fraud APIs return a risk score. Fewer can tell you why. The difference matters operationally: when an analyst reviews a flagged transaction, do they see "risk score: 0.87" or do they see "first-time payee: +0.31, velocity spike: +0.24, device mismatch: +0.18"?

Per-decision feature attribution (using techniques like SHAP) changes how your ops team works. Review time drops because analysts can see the reasons. False positive patterns become visible. And increasingly, regulators in markets like the UK expect evidence chains behind fraud decisions, not just scores.

3. Class Imbalance Handling

Fraud is typically well below 1% of transactions. In many portfolios, it's a rounding error in the data. How the vendor's models handle this extreme imbalance determines whether you get a system that catches fraud or one that drowns you in false positives. Ask specifically: what approach do they use for class imbalance? Standard oversampling (SMOTE) has known limitations at production scale.

4. Integration Complexity

API-first vendors (SEON, Sardine, Unit21) can be integrated in days. Platform vendors (Actimize, Feedzai, SAS) take months. The question is whether you need the platform capabilities or whether a clean API with good documentation is sufficient. For most fintechs, it's the latter.

5. Shadow Testing

The only way to know if a fraud vendor actually works for your transaction patterns is to run it in parallel with your existing stack. Any vendor that doesn't offer a shadow test period is asking you to commit blind. Look for vendors that let you compare decisions side-by-side before going live.

The Bottom Line

Actimize is still the right choice for large banks that need a comprehensive platform with decades of regulatory validation. It's not the right choice for a 200-person fintech that needs to score transactions in real time and can't wait 6 months to go live.

If you're evaluating alternatives, the most important questions aren't about features. They're about latency under your actual load, explainability at the individual decision level, how the system handles the extreme class imbalance that defines fraud data, and whether you can test before you commit.

Note

Canonical version: https://riskernel.com/blog/nice-actimize-alternatives.html

Next read: Fraud Detection API: What to Look For in 2026

Amir Shachar holds 12 patents in fraud detection, cybersecurity, and AI. He spent 4 years at NICE Actimize building fraud models for institutions including Bank of America, and served as Chief Data & AI Scientist at Skyhawk Security. He's the founder of Riskernel.