For many EMI founders, AML enters the conversation too late. First comes the commercial model. Then the product. Then the banking discussion. Then the licence pack starts taking shape, and suddenly everyone remembers that the application also needs an AML framework.
That sequence is one of the fastest ways to make an EMI file look weak.
AML compliance for EMI license applicants is not supposed to be the final stack of policies added before submission. Regulators expect it to be embedded in the business model itself. If an applicant wants to issue electronic money, onboard customers remotely, move funds quickly, work across borders, or use agents and outsourced providers, then the AML design has to exist before the licence file is assembled, not after. The EBA’s authorisation guidelines make this clear by requiring EMI applicants to submit specific information on AML/CFT internal control mechanisms as part of the authorisation package. The same guidelines apply to EMI authorisations through the PSD2 framework used mutatis mutandis for electronic money institutions.
That is the real starting point. The regulator is not asking whether you own an AML manual. It is asking whether your institution is capable of identifying, filtering, escalating, documenting, and reporting financial-crime risk in a live environment from day one.
What the regulator is really trying to understand
When supervisors read the AML part of an EMI application, they are usually trying to answer a small set of practical questions.
Do the founders understand where the money-laundering and terrorist-financing risks actually sit in this business? Is the onboarding model credible? Are customer categories understood? Are the monitoring rules linked to real transaction behaviour? Is someone clearly responsible for AML? Can outsourced or partner-driven activity still be controlled by the EMI itself? Can suspicious activity be escalated and reported without confusion?
Those questions matter because the EMI sector remains under close AML scrutiny. In its 2025 opinion on ML/TF risks, the EBA said competent authorities increasingly assess the inherent ML/TF risk in the electronic money institution sector as significant to very significant, and it pointed to repeated weaknesses in areas such as ongoing monitoring, customer identification, internal controls, and suspicious transaction reporting.
So the AML section of an EMI licence file is not just about compliance language. It is about credibility.
Why generic AML packs usually fail
A common mistake in EMI projects is using generic AML documentation that could belong to almost any financial firm.
That approach creates the appearance of preparedness, but it rarely survives real scrutiny. A generic document may mention customer due diligence, sanctions screening, ongoing monitoring, and suspicious reporting, yet still say nothing useful about the actual risk profile of the applicant. If the regulator cannot see how the AML model connects to the EMI’s products, channels, jurisdictions, customer types, transaction behaviour, and third-party relationships, the application starts to look artificial.
The EBA authorisation guidelines do not ask for abstract AML principles. They ask for specific elements: the applicant’s ML/TF risk assessment, procedures to fulfil customer due diligence obligations, procedures to detect and report suspicious transactions, arrangements for AML training, the identity of the person responsible for AML/CFT compliance, controls to keep procedures up to date, oversight of agents, branches and distributors, and the AML manual for staff.
That is why a reusable template is not enough. The regulator wants to see a control system that belongs to this EMI, not to some imaginary institution.
Start with the risk assessment, not the policy folder
The most useful way to structure EMI AML compliance is to begin with the risk map.
Before drafting procedures, the applicant should be able to explain where the risk comes from. An EMI may be exposed because it serves higher-risk customer segments, supports fast-moving online transactions, relies on remote onboarding, operates across multiple jurisdictions, or uses intermediaries such as agents, distributors, or programme partners. Even a seemingly simple product can generate a complex financial-crime profile once geography, funding methods, redemption logic, and transaction chains are taken seriously.
The EBA’s ML/TF risk factor guidelines require firms to identify and assess the ML/TF risk associated with their business relationships and occasional transactions and to adjust the extent of due diligence according to the risks identified. Supervisors are also expected to use those guidelines when reviewing the adequacy of firms’ AML/CFT risk assessments and procedures.
So the better way to build the AML chapter is not “write policy, then add risk language.” It is the reverse. First define the risk landscape. Then let the procedures flow from it.
CDD must match how the EMI actually acquires customers
Customer due diligence is one of the easiest places for a regulator to test whether the applicant is serious or merely polished.
If the EMI will onboard customers digitally, the application should explain how identity is established, what data sources are used, how the institution handles beneficial ownership, how risk scoring is assigned, when enhanced due diligence applies, and what happens when information is inconsistent or incomplete. If the EMI intends to work with business clients, higher-volume users, cross-border relationships, or complex ownership chains, the file should not describe a retail wallet onboarding model and leave the rest vague.
This is exactly why EMI customer due diligence cannot be treated as a standard flowchart copied from another licence pack. It has to reflect the actual business perimeter. The EBA authorisation guidelines explicitly require EMI applicants to describe the procedures they have in place to comply with customer due diligence obligations.
In practice, regulators usually read this section with one thought in mind: can this firm explain whom it will onboard, how it will verify them, and when it will say no?
Transaction monitoring has to sound operational, not decorative
Many EMI files mention monitoring tools as if naming a vendor solves the problem.
It does not. Supervisors do not care much about the existence of software unless the applicant can explain what the software is actually configured to do. They want to understand the logic behind the alerts, the calibration of thresholds, the investigation process, the escalation path, and the relationship between monitoring and the specific products the EMI will offer.
The EBA’s 2025 sector work makes this especially important. It highlighted weaknesses in ongoing monitoring and improper calibration of monitoring and screening systems in the EMI sector, and noted that supervisors were conducting intrusive reviews focused precisely on issues such as onboarding and transaction monitoring.
A strong EMI transaction monitoring section therefore sounds practical. It explains what is being monitored, why certain scenarios matter, who reviews alerts, how cases are documented, and how the institution learns from false positives and missed signals. A weak one simply says that all transactions are monitored in line with applicable law.
Suspicious reporting needs a route, not a promise
It is easy to write that suspicious transactions will be reported. It is much harder to show that the EMI can actually do it under pressure.
A licensing file should make the internal reporting route obvious. Who makes the first escalation? Who reviews the case? Who decides whether suspicion exists? Who files? How is urgency handled? What happens if the institution cannot complete due diligence but still sees suspicious behaviour? Those are operational questions, not theoretical ones.
This matters even more in the Czech context. The FAU states that an obliged entity must report a suspicious transaction without unnecessary delay, and immediately where the circumstances so require. The Czech AML Act also sets out the content and logic of suspicious transaction reporting.
So the EMI should not describe suspicious reporting as a general duty. It should describe it as a live internal process with ownership, timing, and evidence.
AML governance is where many EMI applicants become unconvincing
Even a technically decent AML framework can look weak if responsibility is blurred.
An EMI application should make clear who owns AML at management level and who is responsible for the day-to-day compliance function. That person needs more than a title. They need defined authority, access to information, reporting lines, and enough organisational standing to challenge the business when needed.
The EBA’s guidelines on AML/CFT compliance officers say that firms should appoint a member of the management body who is ultimately responsible for implementation of AML/CFT obligations and clarify the role of the AML/CFT compliance officer and their interaction with management. The guidelines also stress that the compliance officer should have sufficient authority and that the management body should receive sufficiently comprehensive and timely AML/CFT reporting.
That is the difference between AML governance and AML decoration. One creates accountability. The other creates a name on an organigram.
Outsourcing does not transfer AML responsibility
This is one of the most important points for EMI applicants using third-party providers.
An outsourced KYC tool does not remove the EMI’s obligation to understand its onboarding logic. An outsourced monitoring engine does not remove the EMI’s duty to own alert governance. A partner channel does not eliminate the need for AML oversight. The regulated entity remains responsible.
The EBA authorisation guidelines require applicants to explain how branches, agents and distributors will be controlled for AML/CFT purposes and how those arrangements will not increase the applicant’s ML/TF risk. They also require broader governance and internal control arrangements that are capable of monitoring outsourced functions and preserving the quality of internal controls.
That is where many files start to wobble. The applicant describes the provider, but not the oversight. It names the platform, but not the owner inside the EMI. It refers to contractual obligations, but not to audit rights, sample checks, reporting frequency, escalation routes, or exit plans. Regulators notice that gap quickly.
Czech EMI applicants should build AML around the real local framework
For projects aimed at the Czech Republic, the AML package should not be drafted as a generic EU bundle and localized at the last minute.
The CNB’s EMI licensing page states that specimen application forms and the content of their annexes are prescribed by Czech regulation, and its broader licensing pages tie payment and e-money applications to the Payment System Act framework. Czech AML obligations, meanwhile, sit primarily in Act No. 253/2008 Coll., and suspicious transaction reporting goes to the FAU.
That creates a practical implication: the AML section of the EMI file should already be aligned with Czech legal language, Czech reporting realities, and the actual supervisory expectations the applicant will face after authorisation, not just during filing.
A stronger way to think about EMI AML compliance
The most useful mindset is this: AML is part of the operating model, not an external restriction on it.
If the EMI plans to grow through speed, remote onboarding, cross-border reach, or outsourced infrastructure, then AML has to be designed into those choices from the beginning. The better the AML framework reflects the real business model, the more natural the whole licence file becomes. Governance starts to make sense. Monitoring starts to make sense. Staffing starts to make sense. Outsourcing oversight starts to make sense.
That is why AML compliance for EMI license applicants is not mainly a drafting exercise. It is an architecture exercise.
How AMS Europe helps
AMS Europe helps EMI applicants build AML frameworks that are shaped around the licence perimeter, the real transaction model, and the regulator’s reading logic.
That usually includes drafting or reworking the ML/TF risk assessment, mapping the onboarding and monitoring framework, defining AML governance, setting reporting and escalation routes, aligning outsourced components with internal oversight, and preparing the AML annexes so that they support the wider authorisation case rather than weaken it.
For Czech projects, that also means aligning the AML workstream with the CNB filing framework and the practical obligations that follow under Czech AML law and FAU reporting rules.
Need help with AML, governance, safeguarding, or the full EMI file?
Final thought
A regulator rarely says, “this applicant has too much AML structure.”
More often, the problem is the opposite. The file looks generic. Ownership is vague. Monitoring is abstract. Outsourcing is underexplained. The risk assessment reads like a formality. And the application starts to feel like a business asking for permission before it has built the controls needed to deserve it.
A stronger EMI application does not try to hide that risk exists. It shows that the institution knows where the risk sits and has already decided how to control it.
FAQ
What AML documents should an EMI applicant prepare?
At a minimum, regulators expect an ML/TF risk assessment, CDD procedures, suspicious transaction reporting procedures, AML governance details, training arrangements, oversight of agents or distributors where relevant, and an AML manual or equivalent internal documentation. These elements are explicitly required by the EBA authorisation guidelines and should be tailored to the applicant’s actual business model.
Does an EMI need to appoint an AML-responsible person before licensing?
Yes, the application must clearly identify the person responsible for AML/CFT compliance and demonstrate their experience and competence. It should also explain their role within the governance structure and their interaction with senior management, in line with EBA expectations.
Is outsourced onboarding sufficient to meet AML requirements?
No, outsourcing can support the AML framework but does not transfer regulatory responsibility away from the EMI. The applicant must demonstrate control over the process, including provider oversight, quality assurance, and clear escalation mechanisms.
How should suspicious transaction reporting be organised internally?
Regulators expect a clearly defined internal process, not just a general statement of intent. The application should explain who identifies suspicion, who reviews and decides, who files the report, and within what timelines, with clear ownership and documentation.
Who receives suspicious transaction reports in the Czech Republic?
In the Czech Republic, suspicious transaction reports are submitted to the Financial Analytical Office (FAU). Obliged entities must report without undue delay and immediately where the circumstances require urgency.
How detailed should an ML/TF risk assessment be?
The risk assessment should reflect the actual business model, including products, channels, jurisdictions, customer types, and transaction behaviour. Generic or template-based assessments that lack business-specific detail are usually not considered sufficient.
What role does transaction monitoring play in an EMI application?
Transaction monitoring should be described as an operational system with defined scenarios, calibrated thresholds, and a structured alert-handling process. Regulators focus on how the system works in practice, not just on the existence of a tool.
Are current EBA AML guidelines still relevant after AMLA was established?
Yes, the existing EBA AML/CFT guidelines and standards remain applicable until they are formally replaced by AMLA. Applicants should therefore continue to rely on current EBA guidance when preparing their applications.
