Your Fraud Stack Is Lying To You (But In Predictable Ways)

Bygaz

Wide shot of a dimly lit operations center with large wall displays showing abstract transaction networks and risk heatmaps, a small group of engineers collaborating around a central desk covered in laptops and diagrams, cool blue and amber lighting, shallow depth of field emphasizing interconnected nodes and data flows, cinematic composition

Why this matters this week

If you run any meaningful volume of card, ACH, or open banking payments, your fraud and compliance posture is probably drifting out of sync with reality.

Three concrete shifts that are biting teams right now:

  • Regulators are escalating on “effective controls,” not checklists. Banks and payment processors are pushing that pressure downstream with sharper chargeback rules, monitoring obligations, and data-sharing requirements. “We have a vendor” no longer counts as a control.
  • Fraud patterns have adapted to 3DS, SCA, and device fingerprints. Attackers increasingly use:
    • “Good customer” account takeovers (ATO)
    • Synthetic identities that pass naive KYC
    • Low-value “softening” transactions across multiple PSPs and banks
  • Costs are getting weird. Teams are seeing:
    • Rising fraud losses and rising false positives
    • High dispute ops cost and write-offs
    • Vendor bills that scale faster than revenue

This post is about aligning your payments, fraud, and AML/KYC stack with how money actually moves through your system in 2025, and avoiding the most common engineering traps.

What’s actually changed (not the press release)

Under the buzzwords (“regtech”, “AI fraud detection”, “real-time risk”), the practical shifts for engineers and CTOs are:

1. Liability is moving onto your balance sheet

For card payments and open banking:

  • Card schemes and major acquirers are tightening:
    • Chargeback thresholds
    • Fraud-to-sales ratios
    • Monitoring programs that can lead to fines, reserve requirements, or outright offboarding
  • Open banking and faster payments often mean irreversible transactions:
    • Less room for “oops, we’ll just refund”
    • More expectation of pre-transaction screening and layered controls
  • “We just forward data to our provider” doesn’t fly when:
    • Your upstream asks: “Show us your risk policy, monitoring, and incident response.”
    • Regulators expect explainable detection rules, not a generic “we use ML vendor X”.

2. Data fragmentation is now your real bottleneck

Most orgs now have some combination of:

  • One or more PSPs / acquirers
  • A 3DS or SCA provider
  • A KYC provider (sometimes region-specific)
  • A fraud / risk scoring tool
  • An AML transaction monitoring vendor or bank-hosted solution

But the data actually lives in:

  • PSP dashboards and webhooks
  • Internal event streams or logs
  • Customer support tools
  • Excel sheets in compliance ops

What’s new is not that this is messy; it’s that regulators, partner banks, and auditors now expect coherent, end-to-end evidence:

  • Show a timeline for a suspicious user: onboarding -> first payment -> device changes -> disputes.
  • Show tuning history for your rules and models, and why you didn’t catch X earlier.
  • Show that your sanctions / watchlist checks are timely and complete.

You can’t do that with only vendor dashboards and ad-hoc SQL.

3. “Just add AI” is causing silent capacity risk

Several fraud vendors now default to:

  • Black-box models, with limited:
    • Feature visibility
    • Threshold explanations
    • Drift monitoring
  • “Smart” auto-tuning that:
    • Adjusts thresholds or flows dynamically
    • Is opaque to internal risk & compliance teams
    • Interacts badly with your own rules (“rule wars”)

Net effect for engineering:

  • You ship flows that depend on vendor behavior you can’t simulate or test.
  • When incidents happen, you:
    • Can’t replay decisions easily
    • Can’t quickly change behavior without a vendor ticket and delay

That’s acceptable for an A/B testing tool. It’s not acceptable for core payments and AML.

How it works (simple mental model)

Use this mental model to design / refactor your fintech infrastructure:

Four planes of control: Identity, Transaction, Behavior, Compliance.
Robust systems treat these as separable, composable, and observable.

1. Identity plane (KYC/KYB)

Questions: Who is this? Are we allowed to do business with them?

Components:

  • ID verification (document, biometric, database)
  • Business verification and UBO checks
  • Sanctions / PEP screening

Key principles:

  • Immutable core identity record with:
    • Legal name(s), DOB, IDs, addresses
    • Verification artifacts (what checks, when, result)
  • Append-only updates and audit trails (no silent overwrites)
  • Ability to re-screen all identities against updated watchlists

2. Transaction plane (payments, payouts)

Questions: What is moving? Where? Through which rails?

Components:

  • Card, ACH, SEPA, Faster Payments, RTP, wires, wallets
  • Open banking / account-to-account (A2A)

Key principles:

  • Each movement is a normalized transaction event:
    • Direction (in/out), amount, currency
    • Counterparty attributes (when available)
    • Rail-specific details, but mapped to a common schema
  • Idempotent, traceable transaction IDs across:
    • Ledger
    • PSP/acquirer reference
    • Risk systems
    • Support tooling

3. Behavior plane (fraud/risk)

Questions: Does this pattern look consistent with legitimate behavior?

Components:

  • Device fingerprinting, IP intelligence
  • Velocity checks, behavioral biometrics
  • Risk scoring, rule engine, ML models

Key principles:

  • Risk decisions are derived from identity + transaction + behavior, not siloed streams.
  • Decisions are:
    • Time-stamped
    • Versioned (ruleset / model version)
    • Explainable at least at feature level (“high velocity”, “risky BIN”, “new device”)

4. Compliance plane (AML, reporting, policy)

Questions: Are we fulfilling our obligations to regulators and partners?

Components:

  • Transaction monitoring scenarios
  • Case management
  • SAR/STR filing, regulatory reporting
  • Policy enforcement (limits, restricted countries/products)

Key principles:

  • Policy-as-code where possible:
    • Limits and thresholds in config, not hard-coded
    • Versioned with change history
  • Cases link back to underlying identity / transaction / behavior evidence

If your current system can’t reasonably reconstruct:

  • A single user’s lifecycle over 12–24 months
  • Why a transaction was allowed/blocked at a specific time
  • Why a case was escalated or closed

…then your four planes are entangled or under-specified.

Where teams get burned (failure modes + anti-patterns)

Failure mode 1: “Vendor as system-of-record”

Pattern:

  • All fraud decisions live inside the vendor.
  • Transaction IDs differ from internal ledger IDs.
  • No internal event log of risk decisions.

Impact:

  • Hard to do internal analytics and long-term modeling.
  • Painful audits: you screenshot vendor UI and manually reconcile.
  • Migration risk: changing vendors becomes a multi-quarter project.

Anti-pattern smell:
“Let’s just use the vendor’s customer ID everywhere; we don’t need our own canonical IDs.”

Failure mode 2: Fraud vs. growth civil war

Pattern:

  • Growth pushes frictionless signup and instant payouts.
  • Risk/compliance pushes heavy KYC, holds, and manual reviews.
  • Each team tweaks their own knobs without shared metrics.

Impact:

  • Weird UX: different flows for similar risk profiles.
  • High false positives that support overrides ad-hoc.
  • No clarity on “loss per incremental approval” vs revenue.

Anti-pattern smell:
Risk rules added one at a time after incidents, with no global simulation or rollback plan.

Failure mode 3: AML is bolted on, not designed in

Pattern:

  • AML monitoring is handled by a separate vendor or by the partner bank.
  • Engineers treat it as an integration, not a domain.
  • Transaction schema for AML is different from payments schema.

Impact:

  • Duplicate ETL pipelines and reconciliation logic.
  • Missed complex patterns (e.g., layering across products).
  • Inconsistent narratives in cases vs. transaction history.

Anti-pattern smell:
“AML is just a nightly batch we send to [vendor]; it’s not part of core architecture.”

Failure mode 4: Over-fitting to card fraud patterns

Pattern:

  • System built assuming card-not-present (CNP) fraud is main threat.
  • Same assumptions applied to ACH, A2A, or wallet transfers.
  • KYC tuned for consumer card usage, not higher-risk use cases.

Impact:

  • ATO, synthetic ID, and mule accounts slip through.
  • Faster payments rails used for rapid cash-out once an ATO succeeds.
  • Fraud losses show up as net negative margin cohorts months later.

Anti-pattern smell:
Rules that are all about BIN, CVV, and AVS, and say nothing about cross-rail behavior.

Practical playbook (what to do in the next 7 days)

Assuming you already operate a fintech or payments system.

Day 1–2: Map your four planes

Create a one-page diagram or doc:

  • Identity:
    • Where is KYC/KYB done?
    • Where is identity stored? What are the IDs?
    • How do you re-screen against sanctions/PEP?
  • Transaction:
    • List all rails (card, ACH, etc.) and PSPs.
    • Identify your canonical transaction ID and where it’s used.
  • Behavior:
    • What signals do you collect (device, IP, velocity)?
    • Which decisions are rule-based vs vendor ML vs manual?
  • Compliance:
    • Where does AML monitoring happen?
    • Who owns reporting? How do they get data?

If you can’t complete this without jumping through 5 dashboards and a Slack archaeology expedition, that’s your first problem statement.

Day 3–4: Instrument decision logging

Goal: For any payment or account change, you should be able to answer:
“What were all the risk/compliance decisions that touched this, and why?”

Actions:

  • Define a RiskDecision event schema, including:
    • subject_type (user, transaction, device, payout)
    • subject_id
    • decision (allow, block, review, limit, escalate)
    • reason_codes (e.g., VELOCITY_EXCEEDED, NEW_DEVICE, WATCHLIST_HIT)
    • source (rule-engine, vendor-X, manual-review)
    • ruleset_version or model_version
    • Timestamps and actor (service, human)
  • Emit these events from:
    • Your rules engine
    • Vendor webhooks (wrap responses into your schema)
    • Manual review tools

Store them in something queryable (warehouse/event store), not just logs.

This alone often surfaces:

–

Similar Posts