Data Engineering in Payments: 4 Proven Ways Stripe, PayPal, Visa, and Adyen Conquer Fraud Risks

Data engineering in payments is the invisible machinery that decides, in a fraction of a second, whether your card gets approved at checkout or flagged as suspicious. Most people never think about it. They tap their card, the light turns green, and the transaction is done. But behind that green light sits a pipeline of data moving through fraud models, sanctions lists, ledgers, and compliance checks, all running before the receipt even prints.

Stripe, PayPal, Visa, and Adyen sit at the center of this problem because they process a combined volume of transactions that would be hard to picture in human terms, something closer to the GDP of entire countries flowing through their systems every year. Each dollar carries data: a location, a device fingerprint, a merchant category, a history of prior purchases. Getting that data wrong doesn’t just mean a bad customer experience. It has meant multimillion-dollar regulatory fines, stolen card numbers sold on criminal forums, and companies quietly cutting ties with processors that let fraud slip through.

This article looks at how these four companies actually solve their hardest payment data engineering problems, what’s gone wrong in the industry when this work is done poorly, and what smaller companies can take away from it. We’ll use real, documented cases instead of hypotheticals, because the payments industry has no shortage of them.

What Data Engineering in Payments Actually Means

Before getting into company specifics, it helps to define the term. Data engineering in payments covers the systems that collect, move, clean, and structure transaction data so that other systems (fraud models, compliance tools, reporting dashboards, ledgers) can use it reliably.

This includes:

• Ingestion pipelines that pull in transaction events from card networks, banks, and merchants in real time
• Streaming architecture that processes events as they happen rather than in nightly batches
• Data lakes and warehouses that store years of transaction history for model training and audits
• Identity resolution systems that match a customer, device, or card across multiple transactions and merchants
• Feature stores that feed fraud and risk models with consistent, up-to-date signals

The stakes are unusually high in payments because the data has to satisfy two competing demands at once. It has to move fast enough to approve a transaction in under a second, and it has to be accurate enough to catch fraud, flag money laundering, and survive a regulator’s audit. Most data engineering problems in other industries only have to solve for one of those.

The Real Cost of Getting Payments Data Wrong

It’s worth being honest about why this matters so much, and the clearest way to show that is through cases where the data engineering wasn’t good enough.

PayPal’s sanctions screening failure. In 2015, the U.S. Treasury’s Office of Foreign Assets Control (OFAC) fined PayPal $7.7 million after finding that its automated screening software failed to catch nearly 500 transactions connected to sanctioned individuals and countries, including Iran, Sudan, and Cuba. In one case, a transaction with a person tied to weapons proliferation sanctions went through because, according to PayPal’s own account, an alert wasn’t followed up on for roughly six months. The problem wasn’t a lack of rules. It was a data and process pipeline that didn’t reliably surface the right alert to the right person in time. PayPal rebuilt its compliance data infrastructure afterward, including real-time transaction scanning that didn’t exist during the violation period, as the FTC and OFAC settlement record and related Treasury filings describe.

The CardSystems breach and its fallout on Visa’s network. In 2005, a third-party processor called CardSystems Solutions exposed roughly 40 million card accounts because it was storing sensitive cardholder data it wasn’t supposed to keep, in violation of network rules. Visa and American Express both cut ties with the processor entirely once the scope of the breach became clear. This is one of the earliest large-scale examples of why card networks eventually pushed hard for standards like PCI DSS, which dictate exactly how transaction data has to be stored, encrypted, and deleted.

The BidenCash card dump and Visa’s fraud disruption response. More recently, in late 2023, a cybercrime group known as BidenCash released a batch of nearly 1.9 million stolen card records online, of which Visa’s own fraud disruption team identified around 556,000 Visa accounts as being genuinely at risk. Visa’s report noted that much of this data had been recycled from earlier breaches and linked a portion of it to “enumeration” attacks, where fraudsters use automated scripts to guess valid card numbers by testing small transactions. Catching that pattern requires exactly the kind of real-time, high-volume data engineering in payments this article is about, because enumeration only looks suspicious when you can see thousands of attempts across a wide data set, not one transaction at a time.

Allied Wallet and the payment facilitators that looked the other way. In 2019, the FTC settled with payment processor Allied Wallet and its executives over allegations that the company knowingly processed payments for merchants running pyramid schemes and fake debt collection scams, worth roughly $110 million. According to the FTC’s complaint, Allied Wallet helped these merchants set up fake shell companies and submit false information specifically to dodge the fraud monitoring that card networks require. This case, and a similar 2026 case against Humboldt Merchant Services, show what happens when a processor’s underwriting and monitoring data isn’t rigorous enough to catch merchants who are actively trying to hide.

These cases share a common thread. None of them happened because nobody knew fraud and sanctions violations were possible. They happened because the data pipelines meant to catch these problems had gaps, whether in latency, coverage, or follow-through.

How Stripe Approaches Data Engineering in Payments

Stripe built its reputation on developer experience, but underneath the simple API sits a genuinely complex data engineering in payments problem: scoring risk on transactions from millions of businesses, many of them brand new, with no transaction history to draw on.

Machine learning fraud scoring at the transaction level

Stripe’s fraud product, Radar, relies on a network effect. Because Stripe processes transactions across such a wide range of businesses, it can train fraud models on patterns that a single merchant would never see enough volume to detect on their own, things like a stolen card being tested across dozens of unrelated small stores within minutes. This only works if the underlying data pipeline can anonymize and aggregate signals across customers quickly enough to be useful in real time, not just for after-the-fact reporting.

Event-driven architecture for reliability

Stripe also has to guarantee that a payment event, once it happens, is never lost or duplicated, even during infrastructure failures. This pushes their engineering teams toward event-sourcing patterns, where every state change is recorded as an immutable event rather than overwriting a database row. It’s a heavier engineering lift than a simpler CRUD-based system, but it means a payment’s full history can always be reconstructed, which matters enormously for disputes, refunds, and audits.

PayPal’s Data Engineering Playbook After Its Compliance Wake-Up Call

PayPal’s OFAC settlement described earlier forced a real rebuild of how the company handles compliance data, and it’s a useful case study precisely because the “before and after” is documented.

Real-time sanctions and AML screening

Since the settlement, PayPal has run real-time transaction scanning rather than the slower, less consistent process that existed before 2013. This means every transaction is checked against sanctions lists, politically exposed persons databases, and internal risk flags at the moment it happens, not in a batch job hours later. The data engineering challenge here is less about volume and more about freshness: sanctions lists change, sometimes overnight, and a pipeline that’s even a day stale can let a bad transaction through.

Graph-based fraud network detection

PayPal also invests heavily in graph data structures that map relationships between accounts, devices, and payment methods. Fraud rings rarely operate through a single account; they use networks of linked accounts to spread risk and avoid detection by any one merchant. Representing that as a graph, rather than as isolated transaction rows, lets PayPal’s models spot clusters of related accounts behaving in a coordinated, suspicious way, something a traditional relational database handles poorly at scale.

Visa’s Network-Scale Data Engineering

Visa’s challenge is different in kind from Stripe’s or PayPal’s because Visa doesn’t hold the merchant relationship. It sits in the middle of the network, moving authorization requests between issuing banks and acquiring banks in milliseconds, worldwide, continuously.

VisaNet’s authorization pipeline

VisaNet, Visa’s core processing network, has to route and validate transaction data across thousands of financial institutions with radically different systems, currencies, and regulatory requirements. Visa has said publicly that its fraud detection systems scan thousands of transactions per second, checking for anomalies like a mismatched billing address, an unusually large purchase, or a transaction location far from a cardholder’s typical pattern, all without adding noticeable delay to the checkout experience.

Fighting enumeration and recycled breach data

The BidenCash example described earlier is a good illustration of how Visa uses data engineering in payments defensively rather than just reactively. Visa’s fraud disruption team doesn’t just wait for a data breach to be reported. It actively monitors known criminal marketplaces and correlates leaked card data against its own transaction history to flag accounts before they’re used fraudulently. That kind of proactive threat intelligence work depends on being able to search and cross-reference enormous historical data sets quickly, which is itself a nontrivial engineering problem at Visa’s scale.

Adyen’s Unified Commerce Data Model

Adyen takes a different architectural approach than the other three, and it’s worth explaining because it changes what “data engineering in payments” looks like in practice.

A single platform instead of stitched-together systems

Many payment companies grew by acquiring smaller processors and gateways over time, which leaves them with fragmented data across incompatible systems. Adyen built its platform from a single codebase and a single data model from the start, meaning a transaction’s data, whether it happened online, in-store, or in-app, lives in one unified structure rather than several disconnected ones. This matters for payment data engineering because it removes an entire category of problems: reconciling data formats, resolving duplicate customer records across systems, and syncing risk signals between separate fraud engines.

Compliance and AML monitoring at the platform level

As a licensed financial institution under Dutch and EU regulation, Adyen is required to run know-your-customer (KYC) checks and monitor for money laundering and terrorist financing across its entire merchant base. Its compliance teams investigate flagged transactions, review customer data, and decide whether a Suspicious Activity Report needs to be filed, work that depends entirely on having clean, linked data about who a merchant is, not just what they sold. Because Adyen’s data lives in one system rather than several stitched-together ones, this kind of investigation can pull a merchant’s full transaction and identity history without needing to query multiple disconnected databases.

Common Data Engineering Challenges Across All Four Companies

Despite their different architectures, Stripe, PayPal, Visa, and Adyen run into a similar set of hard problems:

1. Latency versus accuracy – Fraud models need enough data to be confident, but checkout has to happen in under a second.
2. Cross-border regulatory differences – A transaction crossing from the EU to the US can trigger different data retention, privacy, and reporting rules mid-pipeline.
3. False positives – Overly aggressive fraud detection blocks legitimate customers, which costs revenue and trust just as fraud does.
4. Data silos from mergers and acquisitions – Every acquired product can bring its own incompatible data schema.
5. Model drift – Fraud patterns change constantly, so models trained on last year’s data can miss this year’s tactics, as the enumeration attacks described earlier show.
6. Real-time streaming at scale – Batch processing isn’t fast enough anymore; these companies need continuous, low-latency data pipelines that never fall behind.

Lessons for Smaller Payment Companies

Not every business operates at Visa’s scale, but the underlying principles of data engineering in payments apply just as much to a five-person fintech startup as they do to a global card network.

• Screen in real time, not in batches. PayPal’s 2015 settlement happened partly because alerts sat unresolved for months. Even a small team needs a process for acting on flags quickly.
• Don’t store more data than you need. The CardSystems breach happened because the processor kept sensitive card data it had no legitimate reason to retain. Following PCI DSS guidance strictly, even before it’s legally required, avoids this trap entirely.
• Watch your merchants, not just your transactions. The Allied Wallet and Humboldt cases both involved processors that had the transaction-level fraud signals but didn’t act on merchant-level red flags like shell company structures or mailbox-only addresses.
• Invest in graph or network analysis early. Fraud rings rarely look suspicious one account at a time. If your data model only supports row-by-row analysis, you’ll miss coordinated fraud until it’s already cost you money.
• Treat compliance data with the same rigor as fraud data. Sanctions and AML checks are often treated as a checkbox rather than a real-time engineering problem, and that gap is exactly what got PayPal fined.

Conclusion

Data engineering in payments isn’t a back-office technical detail. It’s the reason a checkout button works instantly and safely, and its failures have real, documented consequences, from PayPal’s $7.7 million OFAC settlement to the CardSystems breach that exposed 40 million cards to the ongoing fight against enumeration attacks that Visa tracks in its fraud reports. Stripe, PayPal, Visa, and Adyen each solve this problem differently, whether through network-wide machine learning, real-time sanctions screening, global fraud detection at network scale, or a single unified data platform, but they’re all wrestling with the same core tension between speed and accuracy. For any company handling payments, the lesson from these cases is consistent: the gaps in your data pipeline are exactly where fraud, regulatory violations, and breaches tend to happen.