When I read AMLA’s (EU Anti-Money Laundering Authority's) final draft standards, my first thought was that they looked less like another regulatory publication and more like a product backlog.
The legal language is still there, of course, but behind it sits a rather concrete build list: new customer data requirements, transaction-linking logic, electronic identity, screening rules, back-book remediation and evidence for every CDD (Customer Due Dilligence) decision.
On 1 October 2026, AMLA finalised three sets of draft Regulatory Technical Standards (RTS) under the AMLR. They explain how firms should run customer due diligence, distinguish business relationships from occasional transactions and organise AML controls across groups.The regtech vendors who treat them that way over the next two quarters will win the vendor selections their customers are running right now.
AMLA's RTS drafts from 1 October 2026
AMLA has sent three final draft RTS (Regulatory Technical Standards) to the European Commission, each with a final report and a factsheet. National supervisors helped draft them, and industry feedback from consultations and hearings shaped the final texts. The Commission can still review and amend them, so the provisions become definitive only after publication in the Official Journal of the EU.
AMLA proposes that the standards apply 6 months after they enter into force.
The scope of AMLR RTS
Business relationships, occasional and linked transactions
This standard decides which customers enter the CDD process at all. A business relationship triggers CDD and ongoing monitoring. An occasional transaction below the relevant threshold, usually €10,000, does not, unless one of the AMLR’s exceptions applies.
Firms tell the two apart by looking for repetition or duration: whether the customer has ongoing access to services, whether services will repeat, and whether the engagement runs over a period of time. Transactions count as linked when they share origin, destination, purpose or other characteristics, whether they come from one customer or several acting together. Once linked, their combined value counts against the threshold.
Additionally, some sectors get hard numbers. For instance, for money remittance, currency exchange and crypto-asset exchange, three or more transactions within 12 months indicate repetition, and two or more occasional transactions within one month form the window for linking. For advisers who don’t move money themselves, the value of the underlying asset or transaction counts towards the threshold, regardless of the fee.
For product teams, this means classification logic with rolling time windows and the ability to connect transactions across customers who may be acting in concert. That’s an entity resolution problem as much as a rules problem.
Customer due diligence
CDD (Customer due diligence) is the standard with the heaviest engineering footprint. It defines the data a firm must collect, the sources it can trust and what a remote identity check has to deliver.
The data requirements get granular. For example, firms must capture every name shown on the identity document or electronic identification, a place of birth recorded at least at country and locality level, and an address where country and city, town or village are mandatory. For legal entities, they record the legal name and, where different, the trade name. Firms take reasonable steps to find out whether a person holds more than one nationality, and verifying one is enough.
Capturing that level of detail by hand is slow and leaves room for errors, which is why digital identity verification will carry much of the CDD workload. When the data comes from an eID or an EU Digital Identity Wallet, the attributes arrive already verified against the issuer and go straight into the customer record. Our EUDI Wallet and eIDAS 2.0 accelerator connect those credentials to existing onboarding systems, so firms can accept them without rebuilding their systems.
Proportionality is written into the text. In low-risk situations, firms collect and verify a reduced core set (names, date and place of birth, and nationality or statelessness, refugee or subsidiary protection status) and can skip the address. When an identity document lacks the required data, firms fill in the gaps from reliable and independent sources, and they must be able to understand that information no matter the origin language.
Remote onboarding gets clearer rules too. Annex I of the RTS lists the minimum attributes that electronic identification means and qualified trust services must be able to provide for CDD. Where a customer cannot present a document in person and has no access to eID, firms may use alternative verification methods built on reliable, independent sources and the safeguards in Article 7 of the RTS. AMLA frames this as a financial inclusion measure.
On beneficial ownership, the RTS name acceptable verification sources: business, residence, tax, passport and land registers, reputable data providers, credit and financial institutions, and other obligated entities in the same group. The central beneficial ownership register can help identify an owner in low-risk cases, but register data on its own does not satisfy the verification requirement.
Sanctions and PEP screening can run through automated tools, manual checks or a mix of both. Sanctions screening covers customers and beneficial owners, and PEP checks extend, where relevant, to the people a transaction is carried out for. Aliases, trade names and digital wallet addresses also count as relevant data for sanctions screening, which matters for every product that serves crypto-asset service providers.
Then there is the back book. Customer files that exist when the RTS enter into force must be brought up to standard on a risk-sensitive basis, within one year for higher-risk customers and five years for everyone else, as set out in the AMLR.
Group-wide AML/CFT arrangements
The third standard applies to groups and to networks, partnerships and franchises with common ownership, management or compliance control. Arrangements limited to customer referrals, shared branding or a shared technical platform generally fall outside its scope, which is good news for unrelated firms that run on the same regtech platform.
The EU parent undertaking must run a group-wide AML/CFT framework sized to the group’s complexity and risk. It covers governance and compliance oversight, a group-wide risk assessment, consistent policies, information sharing, staff training and reporting, and a process to fix deficiencies. Entities exchange customer, beneficial ownership, CDD, transaction and risk assessment data on a need-to-know basis, through secure channels, in line with data protection rules, and with documentation. Where third-country laws block that exchange, the entity assesses the barrier, looks for a workable solution and notifies its supervisor.
Who the AMLR RTS apply to?
The standards bind obligated entities under the AMLR. Banks, insurers, asset managers, investment firms, fintech and payment providers sit at the core of that group. AMLA’s factsheets add sector-specific criteria for money remitters, currency and crypto-asset exchanges, gambling operators, auditors, tax advisers, lawyers, real estate agents and football transfers.
For most regtech vendors, the obligation arrives through their customers, who answer to supervisors for every decision the software makes on their behalf. In practice, that means security questionnaires, contract clauses and requests for evidence that a product handles the new data points, time windows and screening scope. We cover extensively how this plays out in procurement in our article on why regtech deals fail on compliance.
What it takes to stay compliant
Most firms are starting further back than the calendar suggests. In a Deloitte study of more than 100 EU financial institutions across 20 countries, published in October 2025, 84% said they had only just started preparing for the EU AML package. Some 86% expected to adjust procedures, internal controls, tooling and technology, and 92% named client data gathering and updating as their top expected gap.
Based on the final RTS, this is where we see the engineering work for obliged entities and the regtech providers that serve them:
- Rebuild the customer data model around the RTS data points: Place of birth, address components, multiple nationalities and entity trade names need their own fields, validation rules and verification status. Free-text fields will not hold up when a supervisor asks which attribute was verified against which source.
- Make classification and aggregation rules explicit: Rolling 12-month and one-month windows, combined thresholds and links between customers acting together should be configurable parameters with version history, so a firm can show which rule applied on which date.
- Support electronic identity, plus a fallback path: Products need to consume the eID and trust service attributes in Annex I and offer a documented alternative route for customers without them. Our eIDAS 2.0 explainer covers the identity side, and our EUDI Wallet accelerator connects wallet credentials to existing onboarding systems.
- Connect screening to onboarding and monitoring: Sanctions and PEP checks need to reach beneficial owners, match on aliases, trade names and wallet addresses, and feed the same customer record that drives risk scoring. This is where most of our KYC compliance software projects start.
- Plan back-book remediation now: A one-year window for higher-risk customers calls for a workflow that segments the portfolio by risk, requests missing data, tracks responses and records outcomes.
- Design group data sharing with controls built in: Need-to-know access, secure channels and documentation are requirements in the group-wide RTS, so permissions, encryption and audit logging belong in the architecture from day one.
- Keep evidence for every decision: Supervisors will expect to trace each CDD outcome to its data, source and rule. Our AML stack diagnostic for regtech product leaders lists ten questions to test this.
Transaction monitoring is where many firms will find the capacity to absorb the heavier CDD workload. In McKinsey’s research, one leading institution improved suspicious activity identification by up to 40% and efficiency by up to 30% after replacing rule- and scenario-based tools with machine learning models. The same research notes that regulators increasingly expect those models to be explainable. If your models also fall under the EU AI Act, the documentation burden grows, which is why we build regtech AI with governance and human oversight from the start. Our piece on agentic AI in compliance covers the build-or-buy decision.
AMLA will keep releasing guidelines and technical standards until July 2027, so tracking them belongs in the plan. Our regulatory intelligence guide by Angel Kurtev, Head of PO Practice at Dreamix, explains how to set that up
The deadline regtech vendors face comes before July 2027
Obliged entities work to the application date. Regtech vendors work to their customers’ procurement calendar, which runs well ahead of it. A bank that needs new screening and monitoring in place by mid-2027 has to select a vendor, integrate and test before then, so the due diligence questionnaire is arriving now. Having previously worked in bank IT and now alongside RegTech product and commercial leaders, I can see why deals stall at exactly this point.
We expect the final RTS to split regtech vendors into two camps during 2027 procurement. One camp can show, on request, the data, source and rule behind every CDD decision under the new standards. The other answers with a roadmap date, and vendor risk teams score a roadmap date as a risk. The second camp will lose deals that never appear as losses in their pipeline reports, because those deals stall quietly in vendor review.
How Dreamix supports regtech providers through the AMLR RTS
Dreamix has built software for regulated industries since 2006, and today we work as a regtech software development partner to regtech vendors and the financial institutions they serve. Off-the-shelf identity and screening tools each cover their own slice well. We build what connects them: integrations with identity providers and screening engines, the customer risk data layer, back-book remediation workflows, audit trails and FIU reporting pipelines. Our partners’ product roadmaps keep moving while the compliance work gets done.
For a leading compliance technology provider with clients in more than 60 countries, we built a production AI platform that connects compliance teams to more than 100 AI models and returns cited, traceable answers from their document libraries. Investigations that used to take an analyst across five or more systems now run in minutes.
As part of the Synechron group, we pair EU nearshore delivery from Bulgaria with financial services regulatory expertise across 21 countries. Our 95% employee retention rate means the engineers who build an AML module are still on the team when AMLA guidance changes. Most of our partnerships run longer than three years, and some longer than ten.
FAQ about the AMLR RTS:
We’d love to hear from you and discuss the best way to meet your compliance needs and business goals.
