Every fraud-platform pitch opens with the model. The vendor wants to talk about the classifier, the graph neural net, the self-learning behavioral engine. It is the wrong conversation, and it has been the wrong conversation for years.

Fraud detection and BSA/AML are not, at their core, model problems. They are data and integration problems wearing model costumes. The classifier is a commodity. XGBoost, graph neural networks, behavioral models: you can buy any of them, and your competitor already has. What separates a system that works from one that doesn’t is whether the right feature is computed, correct, and sitting in memory at the millisecond a decision has to be made.

That backbone is necessary and not sufficient, which is the part most strategy decks skip. Two more constraints sit on top of it, each able to sink a program alone: the people who can actually wield the stack, and the authority to change it once ten stakeholders can each say no and nobody owns the outcome. The interesting failures live in the plumbing, so that is where most of this piece lives.

The safety net is gone

For most of the history of card fraud, time was on the bank’s side: batch settlement and chargeback windows meant a mistake caught an hour later was still one you could unwind. Instant payments deleted that cushion. Once a FedNow or RTP payment is sent the funds are typically gone, and immediate settlement on a 24x7x365 basis compresses the window to detect and stop fraud to almost nothing. Controls designed for batch and delayed settlement are no longer sufficient, and the regulators know it.

The attack surface shifted with the rails. Authorized Push Payment scams convince the customer to authorize the fraudulent transfer themselves, which defeats classic account-takeover signals: from the system’s point of view nothing is compromised, because the real customer on the real device authenticated correctly and hit send. A payment the customer authorized will not trip conventional rules, which is why pre-posting context, payee history, session anomalies, behavioral biometrics, is now required rather than optional.

Supervisors are moving in the same direction. The EU’s Instant Payments Regulation mandated verification-of-payee checks with a compliance deadline of 9 October 2025 for euro-area providers. In the United States, the OCC, Federal Reserve, and FDIC issued a joint request for comment on payments and check fraud, with the debate crystallizing around two poles: shared fraud-data infrastructure versus legal liability. FedNow itself ships native controls such as configurable value and velocity thresholds by customer segment. Those controls are only as good as the intelligence feeding them.

The regulator stopped grading the paperwork

The BSA/AML ground shifted in a way that strengthens the data argument rather than weakening it.

In April 2026, FinCEN proposed a fundamental reform of AML/CFT program requirements under the Bank Secrecy Act, implementing the Anti-Money Laundering Act of 2020 and moving from a checklist, formulaic model to a risk-focused, outcome-oriented one. Programs are to be judged on their ability to identify, assess, and mitigate illicit-finance risk, not on the volume of documentation they produce. Institutions are expected to steer resources toward higher-risk areas instead of treating everything uniformly. And the rule sharpens the line between establishment, meaning program design, and maintenance, meaning day-to-day execution, with supervisory attention on systemic design failures.

The familiar program pillars still stand: internal policies and controls including a risk assessment, independent testing, a designated compliance officer, ongoing training, and customer due diligence, alongside the SAR and CTR obligations every compliance officer can recite in their sleep.

The architectural consequence: effectiveness is provable only if your data can support it. A risk-based program requires a unified, current view of each customer across every channel, because you cannot demonstrate risk-based effectiveness on fragmented data. The reform rewards the exact integration investment this piece argues for, and governance and lineage become how you prove it to an examiner.

Two loops, one backbone

The most common and most expensive design error in this domain is treating pre-posting and post-posting as one problem. They are two problems with opposite constraints, joined by a single spine.

Pre-posting decisioning happens inside the authorization window, and the window is smaller than it looks. A card authorization round trip is budgeted near 100 milliseconds end to end, but network RTT across the rails, the issuer host, and the HSM crypto on the cryptogram consume most of it. What is left for feature retrieval plus model inference is a hard SLA of a few tens of milliseconds. You size that SLA to the tail, not the mean: you budget to p99 and watch p99.9, because the timeout is a hard deadline and a p99.9 miss is not a slow score, it is a forced decision. When the score does not arrive in time, the switch applies its default action, fail-open clears the payment or fail-closed declines it, and either way an unscored transaction resolves. There is no third option.

Living inside a few tens of milliseconds forces two things. First, the model has to be cheap: a gradient-boosted tree or a logistic scorer returns in sub-millisecond to low-single-digit time, which is why those, not the exotic architectures, run the auth path. A graph neural network at tens of milliseconds per inference blows the budget by itself, so it belongs post-posting. Second, every feature has to be precomputed. You cannot compute a customer’s 30-day velocity by querying a warehouse mid-authorization; that value has to already be sitting in an in-memory store, in Redis or an equivalent, served at single-digit-millisecond p99 with no disk in the path, as an aggregate you maintained before the transaction ever arrived.

That maintained aggregate is where most programs quietly break, and the failure has a name: train-serve skew. A feature store has two halves, an offline store the training jobs read and an online store the scorer reads at authorization. If the offline value is computed one way, a batch SQL aggregation over the warehouse, and the online value another way, a streaming job folding events as they land, the two drift apart at the edges: a window boundary defined differently, late or out-of-order events counted in one path and dropped in the other, a timezone, a null coalesced to zero here and left null there. The model then trains on one distribution and scores on another, and its published AUC has nothing to do with its production behavior. The fix is a single feature definition materialized to both stores, write-once and read-two-ways, which is what point-in-time-correct feature stores exist to enforce. Those as-of joins also keep the training set honest by assembling each label from only the feature values knowable before the event, which is the difference between a real backtest and leaking the future into your model.

Post-posting analysis runs without the latency gun to its head, so it can afford the heavy machinery: gradient-boosted ensembles, sequence models for thin-file accounts, and the graph neural networks that surface fraud rings at tens of milliseconds per inference. This is the layer that catches what pre-posting missed, files the SARs and CTRs, and unmasks mule networks by classifying nodes in an identity graph rather than scoring one transaction in isolation.

The join between them is the feedback loop, and it is the piece that decays first when nobody owns it. Confirmed fraud, chargebacks, and analyst dispositions become the training labels and the real-time features that make the pre-posting layer smarter next week than it was this week. That is also where model risk lives: no retrained model reaches the auth path without passing a gate of champion-challenger comparison, a shadow-mode run scoring live traffic without acting on it, and a population-stability check that flags when the feature distribution has drifted out from under the training set. Break the loop and both layers stagnate in place while the adversary keeps learning.

The twenty-portal problem

This is where most programs actually fail, and it is a data and integration problem end to end.

Many institutions run standalone, single-channel tools that create data silos, and those silos fail to link the very data you need to see an omnichannel attack. Survey work has found that half of businesses juggle three or more fraud vendors per use case, each running in its own silo. Once you have 20 or more customer-facing portals, the combinatorics guarantee blind spots, and fraudsters make their living in exactly those seams.

The canonical attack is not sophisticated. A fraudster compiles a dossier on a victim, calls the contact center and authenticates with it, claims trouble logging in, and talks the agent into a password reset. Each step, viewed in its own channel, looks unremarkable. The high-risk pattern only exists when the channels are combined, and no single-channel system catches it because no single channel sees it.

The industry answer has converged on a fraud hub, an orchestration layer that sits above the portals and holds a unified customer view. You consolidate to a Customer 360 on an integration platform with APIs, event-driven synchronization, and real-time enrichment, and you orchestrate rather than rip and replace: the hub ingests risk signals from every channel to sharpen scoring, and investigators get one pane of glass showing where an alert originated, what triggered it, and where the related activity lives.

The key insight is where the work happens. You do not do this at the portals. You do it at a shared event-streaming spine and feature store that every portal feeds and every decision engine reads. The portals become sensors and actuators. The intelligence lives in the middle.

Getting the data in is four problems, not one

“Get the data in” sounds like one task. It is four patterns with radically different latency and cost profiles, and the fraud backbone needs different ones in different places. Getting this mapping wrong is the most expensive architectural error in the domain.

• ETL and batch. Scheduled extract, transform, load. Right for post-posting analytics, model training, and regulatory reporting. Wrong for anything inline, because the irrevocable payment has already settled by the time the batch runs.
• Data virtualization and zero-copy. Query data in place without moving it, the way a lakehouse shortcut is a metadata pointer rather than a copy. Right for stitching a Customer 360 across domains and clouds without physical consolidation. Wrong when you need speed, because a federated query inherits the p99 and the availability of its slowest source and fails when that source fails: you traded reach for a new failure domain, which is how a zero-copy share turns your ETL from bad to worse.
• Zero-ETL replication and mirroring. Log-based change-data-capture that tails the database transaction log, the WAL or binlog, and replays it into an analytical store with no hand-built pipeline. Tools like Debezium land changes in seconds, which is right for keeping the offline and feature layers fresh and fatal for the authorization window, where a few seconds is a few thousand transactions too late.
• Event streaming. The hot path: Kafka feeding a stream processor and an in-memory store. This is where the maintained aggregates are actually built, and where the p99 you spend in the auth window is earned or lost. Wrong for heavy analytical and training workloads, which is why it is a spine, not a warehouse.

The reason the lake cannot serve the hot path is that even its real-time tier batches on the way in. A real-time analytics engine intelligently batches incoming streams into optimally sized files and can deliberately delay writes with a target latency measured in minutes. That engine is genuinely low-latency for interactive queries, dashboards, and near-real-time metrics, and it is well suited to compliance records. But “low-latency analytics” and “score this authorization in 40 milliseconds” are different service levels, and the gap between them is the whole point. I made this same argument about ingestion recently: a pipe can be streaming in name only while the data underneath arrives in batches.

So the clean architectural statement, the one that belongs on the slide, is this. The lakehouse is your analytical spine and your unified-view layer. The streaming and in-memory tier is your decisioning hot path. They are joined by the feedback loop. Serve authorizations off the lake or train models off Redis and you get a system that is either too slow to matter or too shallow to be effective.

It is worth being concrete about how those precomputed aggregates get built, because it is the least glamorous and most load-bearing part of the stack. A feature like “distinct merchants this card touched in 30 days” is a keyed, event-time windowed aggregation over the Kafka stream, computed in a processor like Flink: partitioned by card, held in a RocksDB state backend so the working set can spill past memory, bounded by watermarks that decide how long to wait for out-of-order events before a window closes. Exactly-once matters here for the same reason it matters on the write path: a duplicated event double-counts a velocity feature and a dropped one under-counts it, so the sink commits in two phases against a changelog rather than trusting at-least-once delivery. And because you cannot hold a 30-day exact set of merchant ids per card across millions of cards, high-cardinality features run on sketches, a HyperLogLog for distinct counts or a count-min for frequency, trading a bounded error for a bounded memory footprint. None of this is decoration. It is the difference between a feature that is correct at p99 and one that lies under load.

This also answers the question everyone asks: how many signals do you need? Raw count is the wrong metric. What matters is diversity across categories, because fraud reveals itself at the seams between them: payment message fields, customer-journey telemetry, account events like a new-payee setup or a password reset, historical behavior, and third-party enrichment. Marginal value is wildly non-uniform. A single well-placed cross-channel signal outperforms fifty redundant transaction-level features, which is why an entity model that resolves a customer across systems is worth more than another velocity counter, the same reason banks still cannot solve the data identity problem and why an ERD is the floor, not the ceiling.

When you don’t own the portal

That menu assumes you control the source. In a real estate you do not. Half the portals are SaaS you do not host: a vendor onboarding flow, a third-party contact-center platform, a payments gateway, a KYC provider. You cannot install a Kafka producer in someone else’s product, and you cannot make a vendor support data virtualization or a change feed because your architecture diagram wants one. You get whatever egress the vendor chose to build, and the design bends to it per source.

That egress falls on a ladder, and where a vendor sits on it decides which layer it can feed:

• Native change feed or event stream. The best case. Some SaaS expose one (Salesforce Platform Events and CDC, Stripe events, a Segment stream). Subscribe, normalize, treat delivery as at-least-once, and dedupe.
• Webhooks. Near-real-time push, but you own an ingestion edge that verifies the signature, dedupes on event id, and reconciles, because vendors rarely guarantee ordering or delivery and almost never let you replay a gap. A dropped webhook is silent until a backfill poll notices the hole, which is the same T+1 reconciliation problem streaming was supposed to remove.
• Polling a REST API. When there is only request and response, you pull incrementally on an updated_since cursor and the vendor’s rate limit becomes your freshness floor. If they allow one request a second and you have two million records to page, your “real-time” feed is hours behind by construction. This is a batch pattern wearing a real-time costume.
• Scheduled export or SFTP drop. Pure batch, post-posting only, no matter how much you want it inline.

Two consequences fall out, and both are architectural rather than incidental.

First, you need an anti-corruption layer, not a shared schema. Each vendor speaks its own proprietary event and object model, and you do not let twenty of those into the spine. A per-vendor adapter, an EIP message translator into one canonical event model, is the contract, and the day a vendor ships a breaking schema change on their own release cycle, that adapter is the single place it fails loudly instead of silently poisoning features downstream.

Second, the architecture degrades per source, and you design for that on purpose. A SaaS that only offers an hourly CSV export can never feed the pre-posting hot path, full stop. So you tier the sources: the ones with a native stream or webhooks feed the real-time feature store and the auth-path decision, and the poll-only and batch-only ones feed the offline store and post-posting analytics, where their signals surface in a case review rather than in a 40 ms score. Pretending a batch source is real-time is how you ship a feature that is stale exactly when it matters.

And the coordination is not a sprint, it is a negotiation. Getting a vendor to enable an event feed, raise a rate limit, add a field to a webhook, or sign off on the data-residency and egress terms is contract and procurement work. Every external portal is another party who can say no, and now some of them bill you by the API call. Hold that thought, because it is the same shape as the last constraint in this piece.

Where the platforms actually fit

Name the vendors honestly and the thesis holds up, because the leaders have all converged on unified, streaming, cross-channel architectures.

A lakehouse like Microsoft Fabric earns its place as the foundation, not the trigger. It collapses the silo problem without a rip-and-replace by unifying Spark, SQL, real-time intelligence, and BI over one logical lake. Its data-mesh model maps directly onto the portal problem: each domain owns its data and publishes curated datasets as zero-copy shortcuts, and database mirroring onboards sources with change capture as fast as every 15 seconds. Its real-time tier, the Eventhouse, is the low-latency analytics engine I described above. Governance is built in, because Microsoft Purview enforces sensitivity labels and access policies consistently, which is how you prove the risk-based effectiveness the 2026 FinCEN reform now demands. The caveat is honest: it is an opinionated, Microsoft-centric bet, and adopting it is a strategic lock-in decision an architecture review board should make with eyes open.

Underneath the products sits a vocabulary that predates all of them, and the naming carries real constraints. The Enterprise Integration Patterns, from Hohpe and Woolf, are the timeless description of what a fraud backbone actually is. Each portal is a message endpoint. The fraud hub is a content-based router feeding a scoring service. The feature store is built by aggregators over event streams, and an aggregator is only correct if you specify its three hard parts: a correlation id to group related events, a completeness condition to know when a window is done, and an expiry so a group that never completes does not leak state forever. Because the portals deliver at-least-once, the consumers have to be idempotent receivers that dedupe on event id, or every retry double-scores. Poison messages that will never process go to a dead-letter channel instead of blocking the partition behind them. Reasoning in these product-neutral terms lets you argue about correctness before you argue about tooling.

MuleSoft is one implementation of that vocabulary, structured as API-led connectivity in three tiers with event-driven messaging underneath. For a 20-portal estate its pitch is taming point-to-point sprawl and its failure modes: the custom connection every new system demands, the undocumented flow whose logic lives only in the builder’s head, the silent inconsistency from poor error handling. Same discipline as the lakehouse: it is governed request-and-response middleware, an excellent integration substrate and not your hot-path scorer. Keep it out of the 40 millisecond authorization path.

The convergence is clearest in the vendor category itself. Chartis’s 2025 enterprise and payment fraud quadrant spans FICO, SAS, NICE Actimize, Featurespace, Feedzai, Quantexa, Hawk, and Nasdaq Verafin, and the direction of travel is unmistakable. Feedzai unifies fraud, AML, onboarding, and case management under one framework, explicitly to break down silos, which is the industry admitting fraud and AML draw on the same customer data. Featurespace runs adaptive behavioral models that learn each customer’s normal and adjust to new scams as they appear, which is exactly the self-learning a BSA effectiveness review has to be able to interrogate. FRAML, the convergence of fraud and AML on one data foundation, exists because the data was always shared. The models were the last thing to notice.

Necessary, and not sufficient

Assemble a flawless stack, a lakehouse plus an integration control plane plus a top-quadrant fraud platform, and you can still lose to a scrappier competitor with worse tools. Tools are amplifiers, not substitutes, and they amplify zero as faithfully as they amplify skill.

The stack does not give you the person who can model the fraud domain and know which of hundreds of candidate signals carry marginal lift. It does not give you the feature engineer who controls train-serve skew instead of silently shipping it, the analyst who tunes thresholds against false-positive economics rather than the fraud-caught number, the investigator who turns dispositions into clean labels, or, rarest of all, the one person who owns the feedback loop end to end so the system compounds instead of decays. Three excellent people with a mediocre stack beat a mediocre team with an excellent stack, almost every time.

The false-positive economics deserve their own paragraph, because the arithmetic is brutal and most people never run it. Fraud is rare, call it 0.1% of transactions. Put a genuinely good model on it, 95% TPR at a 1% FPR, and the precision is (0.001 x 0.95) / (0.001 x 0.95 + 0.999 x 0.01), which works out to about 0.087. Nine of every ten alerts that model raises are false, and not because the model is aggressive: it is Bayes. At a 0.1% base rate even a 1% false-positive rate produces roughly ten times more false alerts than true ones, and every one of them lands in a review queue a human works at 1,000 to 5,000 items a day. That is why false declines cost merchants far more than the fraud they stop, by a factor of roughly 13 in long-cited Javelin analysis, and why the 2025 LexisNexis True Cost of Fraud study found fraud raising customer churn for roughly 63% of businesses and poor user experience driving more than a third of account-opening abandonment. You do not fix a base-rate problem by retraining the classifier. You fix it with precision that comes from better features and cleaner identity, applying friction selectively instead of broadly, which is a data problem, not a model problem. Better data lets you stop punishing good customers, and that is usually the larger financial line.

Then there is the constraint that stops well-architected, well-staffed programs cold. A cross-channel change has to touch surfaces owned by many parties: fraud operations, BSA compliance, information security, data and platform engineering, legal and privacy, model risk under SR 11-7, vendor management, and every one of the 20-plus lines of business with its own P&L. Each holds a veto over its own surface. That is ten or more people who can say no, and no single one who owns the cross-cutting outcome with the authority to say yes. The outcome falls between every org box, and the default equilibrium is stasis: the architecture built to be optimized cannot be optimized, because the coordinating authority to change it does not exist. The system rots from unresolvable consensus while the adversary moves faster than any committee.

The fix is org design, not technology. Name a single accountable owner of the financial-crime platform who owns the number rather than a channel, give them a decision-rights framework that separates veto from consultation, and provide executive air cover high enough to bind every affected org. A fraud hub helps, because changing logic in one governed place beats renegotiating across 20 portal teams, but architecture only reduces the number of yeses you need. Org design is what gets it to one.

The bottom line

A solid data and integration strategy is necessary: the right patterns in the right layers, a streaming hot path and a lakehouse spine and a governed integration substrate, joined by the feedback loop. Get it right and everything downstream becomes tractable, more signals, better models, new rails, the 2026 effectiveness-based BSA regime, lower false positives. Get it wrong and no model can compensate, because it will be scoring stale, partial, or skewed data. With 20 or more portals, that backbone is not a nice-to-have; it is the only architecture in which a reliable BSA and fraud system is even definable.

Capable people are necessary too, because the stack amplifies talent and cannot replace it. And the genuinely scarce resource, the one that most often turns a well-architected, well-staffed program into a stalled one, is a single accountable owner with the authority to say yes over ten reasonable noes.

So when you pitch this internally, lead with the architecture, because it is concrete and fundable. Then close on the authority problem, because the people approving your budget are usually the same people who, left unaddressed, become the ten noes.

The figures here are point-in-time and directional; they vary by methodology, and this is a strategy synthesis, not legal or compliance advice. Regulatory and market context draws on FinCEN, the FFIEC BSA/AML Examination Manual, Federal Reserve FedNow materials, Chartis Research, and vendor and analyst documentation from Microsoft, MuleSoft, Feedzai, Featurespace, and LexisNexis Risk Solutions.

---

If you want the data-foundation argument that sits underneath all of this, Foundry and Fabric, Not Foundry or Fabric covers whether the lakehouse hands you a control plane you own or an elegant lease.

I write about AI-assisted development, enterprise architecture, and the infrastructure layer between them. Find me on X @orestesgarcia or LinkedIn /in/setsero.