A new regulatory center of gravity
On July 1, 2025, the EU’s Anti-Money Laundering Authority (AMLA) formally began operations from its Frankfurt headquarters, marking the most significant structural shift in European financial crime oversight in a generation. By the end of December 2025, the European Banking Authority had transferred its AML mandate to the new agency. AMLA’s direct supervision of selected high-risk financial institutions is scheduled to begin in 2028, but its standard-setting work, enforcement signaling, and coordination with national regulators is already underway — and platforms that process cross-border payments are watching closely.
What AMLA represents is not simply a new regulator. It is the culmination of a years-long push toward a single AML rulebook across EU member states: harmonized customer due diligence obligations, unified beneficial ownership verification standards, and a framework under which fines can reach ten percent of annual turnover. For global payment platforms operating across dozens of jurisdictions simultaneously, it crystallizes a challenge that has been building for years. The regulatory environment is no longer a series of discrete national requirements that can be addressed market by market. It has become a continuously updating, cross-border system of obligations — one that rewards architectural readiness and punishes improvisation.
The timing is not coincidental. Since 2020, the pace of payments-related regulatory change has accelerated markedly — from Brazil’s Remessa Conforme rules on international remittances, to the US INFORM Consumers Act, to the EU Digital Markets Act and its implications for marketplace payment flows, to MiCA’s extension of compliance obligations into digital asset infrastructure. AMLA is not a new pressure; it is the institutionalization of pressure that has been building across every major market simultaneously. The question it makes urgent is one that most large platforms have been avoiding: what does it actually take to respond to new regulatory requirements in weeks rather than months?
The hidden cost of siloed compliance
For most large technology platforms, compliance infrastructure was never designed as infrastructure at all. It was designed as a feature , as a set of requirements that each product team addressed in the context of its own launch. The result, almost universally, is a fragmented landscape of parallel compliance implementations: separate identity verification flows, separate risk scoring logic, separate screening against sanctions lists, each built and maintained by a different team with different tooling, different regulatory interpretation, and different timelines.
This model has a logic to it in the early stages of a platform’s growth. Product teams move faster when they own their own stack. Compliance requirements differ enough between products — a marketplace seller onboarding flow and a stored value account have genuinely different risk profiles — that shared infrastructure can seem like premature abstraction. And legal and compliance functions, which have historically owned regulatory interpretation, were not typically structured to drive platform-level engineering decisions.
But at scale, the fragmented model compounds in ways that become structurally unsustainable. Every new regulatory requirement be that a new KYC standard in a target market, a change to beneficial ownership reporting thresholds, an update to sanctions screening obligations — must be implemented independently by each product team. Regulatory expertise is duplicated rather than concentrated. Products reach compliance readiness at different times and to different standards. And the operations function responsible for manual review queues grows linearly with transaction volume because there is no shared mechanism for distinguishing low-risk from high-risk cases programmatically across the organization.
The exposure this creates is not only operational. In a regulatory environment where AMLA can impose fines of up to ten percent of annual turnover for AML failures, and where national regulators — as the UK’s FCA demonstrated with its £28.96 million fine against Starling Bank in 2024 for financial crime failings — are willing to act on systemic deficiencies rather than isolated incidents, the architectural question becomes a risk management question. Fragmented compliance infrastructure is not just slow. In a sufficiently demanding regulatory environment, it is a liability.
From blueprint to reality: The organizational distance
Amazon’s payments organization is one documented example of what this shift looks like in practice. Over a multi-year period, its compliance infrastructure was consolidated from a fragmented set of product-specific implementations into a shared platform serving more than fifteen payment products across the organization’s global markets — a project led by Apurva Shrivastava, a senior product manager in the payments organization, who oversaw the platform from initial architecture through to broad adoption across teams processing hundreds of billions of dollars in transactions annually.
The vendor architecture question
One aspect of the Amazon compliance platform that has received less attention is the strategic treatment of external vendors — and the product discipline required to use them at scale without ceding organizational control over regulatory logic. Identity verification involves capabilities (biometric checks, document validation, sanctions screening) that would be prohibitively expensive to build and maintain in-house across every relevant jurisdiction. The question Shrivastava’s team had to answer was not whether to rely on vendors, but how to structure those relationships so that vendor capabilities slotted into a platform the organization controlled, rather than the reverse.
The outsourcing strategy set an explicit accuracy floor — above eighty percent — as a hard constraint on vendor selection, not merely an aspirational benchmark. Vendor integrations were designed to be pluggable: the platform retained ownership of the decision logic governing when vendor output was sufficient and when a case required escalation, which meant vendor relationships could evolve without requiring downstream product changes. For a platform processing identity verification for over thirty million sellers across multiple geographies, the architectural choice between vendor dependency and vendor composability had direct consequences for how quickly the organization could respond to market-by-market regulatory variation.
The operational impact was substantial. Processing times for seller and customer onboarding, which had previously run across multiple days in the manual-heavy prior model, moved to same-session completion for the majority of cases. Operations headcount, which had been growing in proportion to transaction volume, decoupled from volume growth as the automation layer absorbed the bulk of straightforward cases and routed only genuinely complex ones to human reviewers.
The adoption problem that technology cannot solve
Building a compliance platform that works technically is, it turns out, the more tractable part of the problem. The harder challenge — one that the Amazon initiative had to navigate across a multi-year adoption effort — is organizational: getting autonomous product teams to migrate from their own compliance implementations to a shared platform.
The dynamics of this problem are predictable. A product team that has already built its own compliance stack has sunk cost in that investment. It has legitimate concerns about whether a centralized platform can be configured to meet its specific regulatory requirements. It faces integration risk: moving to a new compliance infrastructure means touching flows that process real transactions, in a domain where errors have regulatory consequences. And it operates under its own roadmap pressures, making the question of when to invest in migration genuinely competing with other priorities.
The approach that proved effective in the Amazon context was to treat the integration experience as a first-class product concern — not an afterthought. API contracts were designed to be highly configurable rather than prescriptive, so that product teams could adapt platform behavior to their specific context without requiring platform-level changes. Documentation, tooling, and integration support were invested in directly, making the mechanical process of adopting the platform as low-friction as possible. And the platform’s value was demonstrated through early adopter integrations before broader rollout was pursued — building credibility with skeptical product teams through concrete evidence rather than internal advocacy.
This last point is worth dwelling on. Internal platforms that are mandated from the top tend to generate compliance in form and resistance in practice. Teams integrate because they have to, not because the platform meets their needs, and the result is brittle adoption that creates problems downstream. The alternative — making the platform genuinely better than what product teams would build themselves — requires sustained investment in the quality of the platform product, not just its capabilities. The Amazon compliance platform’s breadth of adoption (fifteen-plus products across a highly autonomous organization) reflects the fact that this investment was made.
What AMLA changes — and what it doesn’t
AMLA does not change the underlying architectural challenge. Platforms that have already built shared compliance infrastructure have already done the hard work; AMLA is one more regulatory update that their configuration-driven systems can absorb. Platforms that have not are facing the same organizational and technical obstacles they would have faced before AMLA, with the added pressure of a more demanding regulatory baseline and a regulator with harmonized enforcement powers.
What AMLA does change is the urgency of the architectural question. The EU’s single rulebook means that cross-border payment platforms can no longer manage EU compliance as a collection of national requirements with varying implementation timelines. The standards are harmonizing upward, enforcement is becoming more coordinated, and the expectation that platforms can respond to new requirements quickly — rather than across multi-quarter roadmaps — is becoming harder to treat as an aspiration rather than an obligation.
There is a deeper point here that extends beyond AMLA specifically. The regulatory environment for global payments is not going to become simpler. More markets are developing sophisticated payments-specific regulatory frameworks. Existing frameworks are evolving faster than they did a decade ago. Regulatory coordination across jurisdictions, of which AMLA is one example, the FATF’s updated guidance another, is increasing. The platforms that will navigate this environment most effectively are not those with the largest legal and compliance teams, but those with infrastructure that makes regulatory adaptation a product question rather than an engineering project.
The Amazon compliance platform is a concrete case study in what genuine organizational readiness requires — not just technically, but structurally. The architecture it embodies is one answer to the design question; but the harder lesson is about how you get an autonomous engineering organization to actually adopt it. That means treating internal adoption as a product success metric, building credibility through demonstration rather than mandate, and investing in the integration experience as seriously as in the platform capabilities themselves. As AMLA raises both the stakes and the pace of regulatory change, those organizational disciplines are what distinguish platforms that can adapt from those that merely intend to.
