AMLA’s draft Regulatory Technical Standards (RTS) on business relationships and linked transactions are among the most operationally consequential AML texts published in 2026. They determine when customer due diligence is triggered – and by extension, how every transaction monitoring system in the EU must be configured. The final draft should reach the European Commission by 10 July. Here is what compliance teams at financial institutions need to understand before it does (and, importantly, if it does).
Below is an AMLYZE perspective on AMLA’s public consultation on the draft RTS covering criteria for identifying business relationships, occasional and linked transactions, and lower thresholds – and why a RegTech transaction monitoring provider, alongside its peers, has reason to engage.
- Why AMLYZE is reacting to this consultation
AMLYZE is a RegTech company specialising in transaction monitoring, customer risk assessment, and AML/CFT analytics. We are not an obliged entity under Regulation (EU) 2024/1624 (AMLR), but every system we build operates inside the perimeter that this Regulation – and every follow-up implementing instrument, including the Regulatory Technical Standards (RTS) – will define. The criteria that distinguish a business relationship from an occasional transaction, and the criteria for identifying linked transactions, sit at the entry point of the entire AML/CFT lifecycle: they determine when customer due diligence (CDD) is triggered (Article 19 AMLR) and even when an entity becomes an obliged entity in the first place (e.g. Article 3(1) points (i) and (j) AMLR, where status depends on transaction patterns). For obliged entities this means transaction monitoring becomes a core part of compliance even before CDD obligations begin to apply.
Small drafting choices in the draft RTS therefore translate almost directly into the rule libraries, data models, scenario logic, and onboarding workflows that obliged entities must build, validate, and maintain. That is precisely why RegTech providers should engage at the entry point of new regulatory detail: to help clients parametrise their systems correctly, and – where the regulatory position goes beyond what is workable in practice – to take part in the consultation process itself.
AMLA launched the consultation on 9 February 2026, with comments open until 8 May 2026 (23:59 CEST), and held an online public hearing on 24 March 2026. The consultation page and response form are available on AMLA’s website. The empowerment behind the RTS is Article 19(9) AMLR, and AMLA is expected to submit the final draft to the European Commission by 10 July 2026. In the sections that follow, we set out where, in our view, the draft RTS goes beyond what is operationally workable, and we flag those points for AMLA’s attention in the consultation.
- Legal basis: what AMLR allows, what it requires, and why the RTS perimeter matters
The draft RTS does not exist in a vacuum. It implements a specific empowerment under Regulation (EU) 2024/1624 and must be read together with the AMLR provisions it operationalises. The key references are the following.
- Article 3(19) AMLR – definition of ‘business relationship’. A business, professional or commercial relationship connected with the professional activities of an obliged entity, set up between an obliged entity and a customer, including in the absence of a written contract, which is expected to have, at the time when the contact is established, or which subsequently acquires, an element of repetition or duration. AMLA has confirmed in the public hearing that this definition is set by AMLR itself and that the RTS does not, and cannot, change its logic; the RTS mandate is limited to defining the occasional transaction and the criteria around it. The ‘expected’ element is decisive: duration or repetition does not need to materialise over a longer horizon – expectation at the moment of contact is sufficient.
- Article 3(20) AMLR – definition of ‘linked transactions’. Two or more transactions with either identical or similar origin, destination and purpose, or other relevant characteristics, over a specific period. Again, this definition is fixed by AMLR. The RTS empowerment is to specify the criteria and elements that obliged entities must take into account when applying it.
Occasional transaction vs business relationship: when CDD is triggered under AMLR - Article 19 AMLR – situations triggering CDD. Article 19(1) sets out the situations that trigger the obligation to apply CDD measures AND that fall within the scope of the draft RTS: when establishing a business relationship; when carrying out an occasional transaction of a value of at least EUR 10 000; and when carrying out occasional transactions in cash of at least EUR 3 000 (or a lower national threshold, where a Member State has set one). For transfers of funds within the meaning of the Funds Transfer Regulation, AMLR sets a separate lower threshold of EUR 1 000. For providers of gambling services, AMLR requires CDD upon the collection of winnings, the wagering of a stake, or both, where the transaction amounts to at least EUR 2 000. All value-based thresholds must be assessed taking linked transactions into account: where two or more transactions are linked, the threshold must be tested against the aggregate, not against each transaction in isolation.
- Article 20 AMLR – CDD measures. Identifies what ‘full CDD’ actually means: identification and verification of the customer and beneficial owner, understanding the purpose and intended nature of the business relationship, and the basis for ongoing monitoring. Why this matters: every additional case that the RTS classifies as a business relationship – or that reaches the indicated value-based threshold – triggers the full Article 20 package. Over-classification is therefore not a definitional curiosity; it is a direct cost on customers, providers, and supervisory bandwidth.
- Funds Transfer Regulation framework. Recognises that, by design, certain transactions do not carry comprehensive payer/payee information – in particular small-value transfers below EUR 1,000 and certain card-based flows. Why this matters: the RTS cannot lawfully require obliged entities to identify linked transactions on the basis of data that the EU framework itself does not require them to collect. The ‘information available’ principle is therefore not a drafting preference; it is a consistency requirement across the EU AML framework.
- AMLYZE’s central message: transaction monitoring starts before the business relationship does
The draft RTS treats the question of when a business relationship arises as a binary, downstream issue: once the duration or repetition criteria are met, the relationship is established and CDD is triggered. This is where the current draft raises the most significant concern across the market – among obliged institutions and vendors alike. The thresholds are set so low that the risk-based approach AMLA has consistently advocated risks collapsing, in practice, into a low-threshold rulebook. By the time three transactions have occurred in twelve months (Article 2(3)), or linked transactions have crystallised over a one-month rolling period (Article 3(2)), the patterns AMLA cares about have already taken place – and full CDD must be put fully in motion after the fact.
Our position is straightforward: monitoring of interlinked patterns must be performed before a business relationship is formally established, and before any decision is taken on whether to apply full CDD measures.
In practice, this MIGHT mean few things if draft RTS remains unchanged:
- Pre-relationship pattern monitoring. From the very first occasional transaction, the obliged entity must be able to detect emerging linkages – same originator, same beneficiary, same device or IP, same purpose, structuring patterns – in real time. Waiting until the third transaction, or the end of the rolling period, is by definition too late.
- Cross-customer and cross-counterparty linkage detection. Linked transactions under Article 3 are not always linked at the level of a single customer. They can involve multiple originators sending to one beneficiary (or vice versa), ‘operating in concert’ patterns, shared digital infrastructure, or transactions pertaining to the same purchase. These signals only emerge if the monitoring system looks across the population, not just within an individual customer file.
- Decision support for the CDD trigger itself. The outcome of pre-relationship monitoring should feed directly into the decision on whether the activity has crossed into a business relationship, and whether enhanced or simplified CDD applies. Treating monitoring as a post-CDD activity inverts the logic: monitoring is what tells you whether you are in a relationship – not the other way round.
The underlying intention of AMLR is clear and, in our view, correct: the business relationship and linked-transaction concept exists precisely to stop criminals from splitting a single economic event into transactions that individually fall below the CDD threshold. We do not question that intention. The difficulty, as so often in EU AML/CFT regulation, lies in the implementing detail. The draft RTS must capture that intention without imposing on legitimate, low-risk businesses a duty to collect, retain and analyse data they do not need or– under the Funds Transfer Regulation framework – are not required to obtain. Where the criteria are drafted too mechanically, and uncoupled from the actual financial-crime risk a transaction presents, the result is not better prevention; it is additional bureaucracy imposed on low-risk payments that no realistic risk assessment would flag, while the resources that should be directed at genuine illicit-finance patterns are diluted. The remainder of this paper is concerned with that calibration: how to keep AMLR’s anti-circumvention purpose intact while ensuring that the operative text of the RTS does not, in practice, penalise the customers and business models the framework was never aimed at.
- Article-by-article comments on the draft RTS
The sections above set out our overarching concern: that the draft RTS, by anchoring the existence of a business relationship in low, mechanical thresholds, risks turning the risk-based approach into a low-threshold rulebook that activates after the fact. The provisions below are where that concern crystallises in operative text. We comment only few provisions article-by-article – each provision translates, almost directly, into a configuration choice in our customers’ transaction monitoring and onboarding systems – a rolling-period parameter, a counter, a linkage rule, a carve-out, a data field that may or may not be available in the payment message. As a RegTech provider sitting next to obliged entities while they parametrise these systems, we see where the drafting is workable, where it is operationally fragile, and where it goes beyond what AMLR itself or the Funds Transfer Regulation requires obliged entities to collect. The comments that follow flag those points for AMLA’s attention.
Article 2(1) – online registration as a trigger for establishing a business relationship. The provision treats the use of online services through a registration providing ongoing access as a duration criterion. We agree it is relevant, but it should be indicative rather than determinative. In digital business models, registration is often a purely technical access mechanism – for example, apps used to make a single tax, utility, or parking payment, where the user has no expectation of repeated use and may use a different provider next time.
Article 2(3) – three transactions in 12 months as a trigger for treating activity as a business relationship (currency exchange, money remittance, certain crypto-asset services). This is the most operationally consequential trigger in the draft RTS, and the most structurally inconsistent with a risk-based approach. AMLR Articles 19(2) and 19(4) already set value-based thresholds (EUR 1,000 / EUR 3,000), and Article 19(1)(d) preserves suspicion-based triggers. A fixed count overlay produces the absurd outcome that three EUR 1 transfers establish a business relationship, while a single EUR 999 transfer does not.
AMLA itself acknowledged at the hearing the conflict with the EUR 1,000 remittance threshold, and indicated no immediate view on which prevails. The trigger should be re-anchored in cumulative value, and/or in a higher count over a shorter observation period. For low-risk, high-volume use cases (utility bills, taxes, parking, public transport), an explicit carve-out or proportionate treatment is warranted.
Article 3(1) – criteria for linked transactions triggering CDD. The criteria are conceptually right but operationally fragile. To monitor against them, the data the criteria rely on must actually be present in the transaction message in the first place – yet the Funds Transfer Regulation (Regulation (EU) 2023/1113, ‘TFR’) itself might carve out situations where that data might be, by design, either absent or not verified (e.g. transfers carried out by payment cards, electronic money instruments, mobile phones and similar prepaid or postpaid IT devices used exclusively for the purchase of goods or services). The ‘information available’ limitation acknowledged in Recital 11 of the draft RTS must therefore be lifted into the operative text of Article 3. Without it, Article 3(1) reads as a de facto data-collection and verification obligation that goes beyond what the TFR itself imposes – forcing obliged entities to either obtain data the EU framework expressly does not require them to collect.
Article 3(2) – one-month rolling period for linked transactions. A one-month rolling period is significantly too long relative to existing supervisory experience. Several Member States – notably Lithuania – have applied a 24-hour rolling period under their AMLD4 implementations, and those regimes have been evaluated by MONEYVAL without any findings of elevated ML/TF risk attributable to the shorter timeframe. A mandatory floor of one month is not supported by the available evidence base; it does not respond to a documented ML/TF risk. What it does do is sweep up entirely legitimate low-risk cumulative flows. Monthly utility bills routinely exceeding EUR 1,000 in colder EU regions during heating season, recurring tax and public-sector payments, school fees, parking and public-transport top-ups, and instalment payments will, on the face of Article 3(2), be treated as ‘linked’ – with the result that the obliged entity must identify and verify ordinary citizens making ordinary payments to the state, to municipal utilities, or to regulated public-service providers. The bureaucratic burden falls disproportionately on low-risk business models, and the corresponding cost falls on customers – who, in practice, find that paying their heating bill, topping up a transport card, or settling a tax invoice triggers an identification and verification process originally designed to detect organised illicit-finance schemes.
The effects of mentioned clauses in RTS is sharper still in smaller, more concentrated EU markets, where the same payer–payee combinations recur naturally because customers have few practical alternatives – a single national heating utility, a single transport operator, a small set of municipal services, a limited domestic remittance corridor. In those markets the rolling-period rules do not separate suspicious recurrence from structural recurrence; it captures the structural one as well, and treats the absence of choice as if it were a pattern of concern. This is a direct obstacle to access to basic financial services, and it is precisely the outcome the risk-based approach AMLA has consistently advocated is supposed to prevent. We recommend that AMLA review existing national practices and lower the floor accordingly, and pair the lower floor with an explicit carve-out for low-risk public-sector and utility flows.
These are some of the points AMLYZE invites AMLA to consider, alongside the broader set of observations submitted by the Lithuanian Fintech Association (formerly Fintech Hub LT) on behalf of the Lithuanian fintech sector.
- What this means for transaction monitoring system design
Whatever final form RTS takes, transaction monitoring systems will need to take into account several dimensions. First, monitoring rules must run from the very first transaction, not from the moment a business relationship is formally recognized – linkage detection, structuring detection, and counterparty-network analysis are pre-relationship controls. Second, scenarios must be configurable to whichever rolling period and threshold combination ultimately prevails (24 hours, one month, cumulative value, count-based), and they must support sector-specific carve-outs for low-risk models. Third, the ‘information available’ principle must be honoured at the data layer: monitoring should escalate based on what the obliged entity actually has, not on a presumption of data the regulation does not require it to collect.
- Why RegTech providers should engage, even though they are not obliged entities
AMLYZE, like other RegTech vendors, is not an obliged entity under AMLR. If we do perform CDD on end customers it is not because we are obliged by AMLR; we provide the systems that obliged entities use to comply. That distinction does not, however, make the upcoming regulation any less relevant to us – or to our peers. If anything, the opposite is true. Every change in the operative text of the RTS, every clarification (or absence of one) in a recital, and every decision on thresholds and rolling periods translates almost directly into product requirements, rule libraries, data models, and onboarding workflows that RegTech providers must build, validate, and maintain flexible to all upcoming changes.
RegTech providers therefore have a threefold responsibility. The first is to remain vigilant on upcoming regulation – tracking AMLA consultations, EBA opinions, the Funds Transfer Regulation framework, and the forthcoming AMLA Guidelines on transaction monitoring as a single coherent stack, not in isolation. The second is to offer constructive comments where the regulation, as drafted, fails to meet operational reality. We see what our customers see: the data that is and is not available in real-life payment messages, the false-positive rates produced by overly rigid count-based triggers, the user-experience cost of treating every utility-bill payer as a business-relationship customer, and the structural mismatch between one-month rolling windows and 24-hour patterns of laundering behaviour. That perspective belongs in the consultation process. The third is to keep the technology itself flexible. The regulatory landscape is moving fast – new RTS, evolving AMLA expectations, recurring revisions of national supervisory practices – and obliged entities cannot afford a vendor whose rule libraries, data models, or scenario logic require a major release cycle every time a threshold or rolling period changes. RegTech systems must be parametrisable, configurable, and quick to adapt, so that compliance teams can absorb regulatory change as soon as it lands rather than wait for it.
Our message to fellow RegTech providers is therefore the same as our message to obliged entities: read the draft RTS, attend the hearings, file comments – and, above all, design transaction monitoring on the assumption that the relevant patterns must be visible before, not after, the regulation says a business relationship exists. The risk-based approach that AMLA itself has consistently advocated only works if the systems supporting it are forward-looking by design.
AMLYZE will continue to monitor the consultation process and to contribute commentary as the RTS, and the further AMLA Guidelines on transaction monitoring move toward final form. RegTech is not on the sidelines of AML regulation – it is part of the infrastructure that determines whether the regulation works in practice.
AMLYZE transaction monitoring is designed to run from the very first transaction — before a business relationship exists, before CDD is triggered. See how it works.
