Open source AML for the EU AMLR

Open source AML for the EU Anti-Money Laundering Regulation: what it asks of your stack

If you are an EU obliged entity or fintech planning self-hosted monitoring and screening before the single rulebook applies from 2027, expect open-source tools such as Jube and yente to carry the detection and screening work, but expect the regulation itself to be met by documented controls, records and governance that no tool provides on its own. The question for your stack is not only whether it can flag a suspicious payment or a sanctioned name, but whether you can show how each alert, decision and rule change was produced, reviewed and retained. Regulation (EU) 2024/1624 sets out the EU's single anti-money laundering rulebook, which covers customer due diligence, ongoing monitoring, and the internal policies and procedures obliged entities must maintain. The regulation also establishes the Anti-Money Laundering Authority (AMLA) to coordinate and supervise in the area. In plain terms, you must know your customers, understand their risk, watch their activity over time and be able to explain those duties to a supervisor. Article-level references in this section, and in any internal mapping you build, must be confirmed against the official text on EUR-Lex and the current supervisory publications, because the wording and the sequence of application dates matter for your plan.

Start by listing which duties your entity carries directly and which depend on a third party, such as a sponsor bank or outsourced screening provider. For each duty, record the system that performs it, the person accountable for its outcome, the data it reads and the evidence it writes. Confirm with your compliance function and counsel which national rules and supervisory expectations apply in each Member State where you operate, since the single rulebook is applied alongside national arrangements. This map becomes the spine of your implementation scope and of the documentation you will eventually hand to supervisors, and it shows early where a self-hosted tool needs an adjacent control, such as access logging or change approval, that you must build yourself.

Which AML duties the function must cover and how to configure each one

This table maps each core AML duty under the EU rulebook to what a self-hosted function must do and how to configure Jube, yente with OpenSanctions data and the records store. Read each row as a design requirement to confirm with your compliance team and the article references in Regulation (EU) 2024/1624 before configuration begins.

Duty area	What the self-hosted function must do	How to configure it
Customer due diligence data capture and verification records	Capture identity, purpose and ownership data at onboarding, keep verification evidence and link it to each customer file for later review.	Store onboarding fields and verification evidence in the records store with timestamps and reviewer IDs. Feed customer attributes into Jube so monitoring uses the same profile. Confirm the required data points against Regulation (EU) 2024/1624.
Sanctions and PEP screening of customers and beneficial owners	Screen customers, beneficial owners and representatives against sanctions and politically exposed person lists at onboarding and on list updates.	Run yente against OpenSanctions data inside your network, set match thresholds with documented rationale, and log every query and result. Confirm the screening scope and frequency in Regulation (EU) 2024/1624 and your own risk assessment.
Ongoing transaction monitoring and scenario tuning	Monitor transactions and customer behavior over time against typologies relevant to your business and customer base.	Define scenarios and thresholds in Jube, back-test them on historical data, and record each change with its reason and approver. Confirm monitoring obligations and risk-based expectations against Regulation (EU) 2024/1624.
Alert triage and case handling	Route alerts by risk, assign them to analysts, record investigation steps and close alerts with a documented outcome.	Configure Jube alert queues, priority rules and mandatory disposition codes. Keep case notes and attachments in the records store with access logs. Confirm escalation and review timing with your compliance function and the applicable article.
Suspicious activity escalation and record keeping	Escalate suspicious activity to the designated reporting function and keep records of the decision, including decisions not to report.	Build an escalation workflow that stores the rationale, reviewer and submission reference. Set retention periods in the records store according to the regulation as confirmed against Regulation (EU) 2024/1624 and national rules.
Governance of rules, models and lists	Document who approves monitoring rules, screening thresholds and list sources, and show how changes were tested before release.	Version control rule and threshold files, require a second approver for changes, and log yente list refresh dates and sources. Keep a validation file for supervisors. Confirm governance expectations in Regulation (EU) 2024/1624.

How AMLA supervision changes what supervisors will ask for

A single EU rulebook and AMLA supervision mean that supervisors will not stop at asking whether alerts were generated and cases were closed. They will ask how the monitoring and screening system was designed, configured, tested and changed, and whether a third party could reconstruct that history from the records. A working system and a documented system are different things. A self-hosted Jube deployment can detect suspicious patterns correctly and still fail an examination if the rule set, model versions, threshold values and data sources cannot be traced to a dated decision, an owner and a test result. Plan the evidence set alongside the build: design documents, configuration baselines in version control, change tickets with approvals, and regression test results for each release of rules, models or yente data.

Expect supervisors to probe the reasoning behind each rule and threshold setting, not only the setting itself. For a given typology, the file should show why a threshold was chosen, what false positive and false negative trade-offs were considered, who approved it, what data it was tested against, and when it was last reviewed. The same applies to fuzzy matching thresholds in yente and to any suppression or whitelisting logic, because these are the settings most likely to be questioned when alert volumes fall. Ask your compliance function to name the owner of each setting and the review cadence before go-live, and confirm that your change process can produce that record without manual reconstruction.

Confirm how supervision will apply to your entity type before you design the evidence set. The topic facts supplied for this page do not include AMLA's supervisory timetable, the entities it will supervise directly, or the scope of national competent authorities' roles, so do not plan around dates or categories you have not verified. Ask your national competent authority for its expectations on documentation and examination, and ask counsel to confirm which obligations apply to your institution, sponsor bank arrangements and outsourced components. Record those answers in writing, because they determine how much design and change evidence you need to hold on your own infrastructure.

Which open-source platforms fit EU AML monitoring and screening

This section maps each platform to a job in an EU AML stack: monitoring, screening, customer data, payment events, case records and access control. Each card names what the component covers, what it leaves to other systems, and what to confirm in your own environment before you commit. No platform listed here holds a certification or regulatory approval for AML use.

Jube for transaction monitoring

Jube is the monitoring engine in this stack, suited to teams that want rules, models and case handling in one self-hosted service. It scores transactions and raises alerts that analysts work through a case queue. Jube does not decide what is suspicious, because your risk assessment and typologies set that. It also does not supply sanctions lists or file reports with a financial intelligence unit. Confirm the license terms for your use, how rule and model changes are versioned, and which Jube release your validation covers.

yente for sanctions and PEP screening

yente runs sanctions and PEP matching against OpenSanctions data, so customer names can be screened inside your network without sending them to a hosted lookup. It covers matching and scoring of names against listed persons and entities. It does not cover adverse media, the clearing or escalation of a match, or ownership analysis beyond what the source data carries. Confirm the OpenSanctions data license for internal commercial use before go-live, along with the refresh cadence your policy requires and the matching thresholds your validation supports.

Apache Fineract as customer and account data

Apache Fineract fits where it is the core banking system of record, because monitoring and screening need a reliable feed of customer, account and transaction data. It is licensed under Apache-2.0, and its 1.15.0 release was published on July 14, 2026, which is a starting point for version planning. Fineract supplies data but does not screen or monitor it. It also holds only the data your integrations and product configuration put into it. Confirm which customer identifiers, beneficial owner fields and transaction event types your deployment exposes, and whether your version receives security fixes.

Hyperswitch as a payment-flow source

Hyperswitch fits where card and account payments already pass through a self-hosted orchestration layer, because it can emit payment events that monitoring scores in the flow. It is licensed under Apache-2.0 and offers both SaaS and self-hosted options, and v1.128.0 was published on October 16, 2026. Payment events are the monitoring input, not the monitoring itself. Any path that handles cardholder data brings PCI DSS scope into the design. Confirm which payment, payout and fraud providers feed your events and which fields leave the cardholder data environment.

Records and case store

Monitoring and screening produce alerts, decisions and evidence that must be kept and retrieved later, so the database holding cases needs its own design. Choose a store that keeps an append-only history of case changes, enforces retention rules and exports records in a form supervisors can read. Retention period is a legal decision. Confirm the duration under the EU AML rulebook and your national rules with counsel. Decide who can edit closed cases and how each change is logged.

Identity and access around the case queue

Identity and access controls determine who can see alerts, open cases and close them. Use single sign-on with multi-factor authentication, enforce role separation so an analyst cannot approve a closure they opened, and log each access and change. The GDPR text expects security measures suited to the risk under its security of processing duty, so keep the control design and access review evidence in the case file. Confirm your identity provider, how privileged administrators are reviewed, and how access reviews are recorded.

How the stack changes across cloud, data center and air-gapped deployments

In a client-owned cloud account, Jube, yente, the OpenSanctions refresh job and the case store run as containers or virtual machines inside the client's own subscriptions or projects, with the client holding the encryption keys and the administrative roles. The refresh pipeline pulls source data over outbound connections that the client can allow-list, and the output is written to storage the client controls. Customer and transaction data stay in the regions the client selects, but the cloud provider's own operations staff and sub-processors are part of the picture and must be documented.

Component placement: Jube, yente and the case store can sit in private subnets behind a gateway, with the refresh job running on a schedule and writing to an internal index.
List updates: the refresh job retrieves OpenSanctions data over an outbound path, so the egress rule and the proxy log become evidence of how each list version arrived.
Backups: snapshots of the case store and rule configuration go to a separate region or account, encrypted with keys the client manages.
Access logs: control-plane logs, host logs and application audit trails should go to a log store with restricted write and read roles and a defined retention period.
Data location: confirm the region of every service, backup, log sink and support access path, including where the provider's staff can reach the environment.

Before committing, confirm with the cloud provider where each managed service stores data and which sub-processors could access it.

How GDPR shapes screening and monitoring of personal data

Screened and monitored data about customers and beneficial owners is personal data under the GDPR (Regulation (EU) 2016/679), so every self-hosted screening and monitoring component needs a documented role assignment before go-live. The institution that decides why and how a name is screened against a list, or why a transaction is scored, is the controller. A vendor or implementation partner that runs Jube, yente or a list refresh pipeline on the institution's behalf is generally a processor, and the written contract must set out the processing instructions, the data categories and the sub-processors. Confirm with your data protection officer whether any operator of the stack, including a partner with administrative access, could see live personal data, because that access changes the processor analysis and the contract scope. Article 32 (security of processing) is where the technical evidence sits. Expect to show encryption of case files and alert stores, access control on rule and model configuration, logging of who viewed or changed a screening result, and a tested restore of the case database. Articles 33 and 34 set the breach notification clock and the duty to inform affected individuals where risk is high. Map which logs, queues and backups hold screening hits, since a leaked hit list that reveals a person was flagged can itself be a reportable breach. Transfers under Chapter V apply when list data is pulled from, or a hosted service processes names in, a country outside the EU or EEA. The EU-US Data Privacy Framework decision (Commission Implementing Decision (EU) 2023/1795) is the starting point for US-based hosting, and you should confirm its current status with counsel. The GDPR requires no audit report, attestation or certificate. Certification under Article 42 is voluntary, lasts for at most three years, and does not reduce the controller's or processor's responsibility. Treat any certificate a vendor offers as supporting evidence, not as proof of compliance. Finally, the Omnibus IV proposal (procedure 2025/0130(COD)) has a text agreed on 26 June 2026 awaiting Parliament's first-reading vote, and the Digital Omnibus proposal (procedure 2025/0360(COD)) is awaiting committee decision. As of October 2026 the GDPR text itself has not been amended, so confirm the current consolidated text and any changes before you finalize your records of processing and retention rules.

Which evidence supervisors and auditors ask for and which component produces it

This table maps the evidence a supervisor or auditor is likely to request for self-hosted monitoring and screening to the component that generates it. Read each row as a question to answer before the assessment starts, not as proof that the control works. The auditor or supervisor decides whether the evidence is sufficient, and DeployOpen prepares it without issuing any attestation.

Evidence item	What it shows	Component that produces it
Rule and model inventory with version history	Which scenarios, rules and models were live on a given date and who approved each version	Jube rule and model configuration under version control, plus the change register
Documented rationale for thresholds and scenarios	Why each threshold and typology was chosen, tested and accepted by the business owner	Model validation documents and tuning records kept with the rule inventory
Screening configuration and matching thresholds	The fuzzy matching settings, list selections and score cut-offs in force during each period	yente configuration files and deployment records
List source and refresh logs	Which OpenSanctions datasets were loaded, when, and from which version, plus failed refresh attempts	Data update pipeline logs and dataset version records
Alert and case audit trail with timestamps and user actions	Who opened, reviewed, escalated or closed each alert and case, and when	Jube case management log and database audit tables
Change management records for rules and deployments	Approval, testing and release steps for each rule change and software upgrade	Ticketing or Git workflow, CI/CD pipeline logs and release notes
Access logs and multi-factor authentication records for case users	Who accessed case data, from where, and whether MFA was enforced at sign-in	Identity provider logs and application access logs
Backup and restore test records	That data and configuration can be recovered and that restores were tested, with results	Backup tool job reports and documented restore test outcomes
Data location and processor records	Where screened and monitored personal data is stored and which parties process it	Infrastructure inventory, hosting contracts and processing records maintained by the client

What tooling alone does not satisfy

Jube and yente can detect, score and screen, but the EU framework places accountability for risk assessment, due diligence, reporting and evidence on the obliged entity. The cards below mark what your own people and governance must own, and where a partner can help prepare the work without taking those decisions over.

Institutional risk assessment and policies

Your business-wide money laundering and terrorist financing risk assessment, and the internal policies and controls built on it, must be written and approved by your own management body. The monitoring rules, thresholds and screening settings should trace back to the risks you identified, not to vendor defaults. Own the risk appetite and sign-off. A partner can help map identified risks to configurable rules, document the link between them, and set up a review cycle that records when the assessment changed and why.

Customer due diligence and onboarding review

Identifying customers, verifying beneficial owners and deciding whether to onboard or refuse are judgments that the institution must make and be able to explain. Screening hits and risk scores support those decisions but do not make them. A person with authority must review and record each onboarding decision, including high-risk and escalated cases. A partner can help design the review queue, the evidence fields captured at each step, and the data flows from onboarding into monitoring.

Staff training and case handling capacity

Analysts who triage alerts, investigate cases and escalate suspicion need documented training and enough time to do the work properly. A tool that produces alerts faster than the team can close them creates a backlog that supervisors will read as a control weakness. Staffing and training are your obligations to size and evidence. Ask a partner to help set up case queues, service-level tracking for alert ageing and training records that show who was trained on which procedure and when.

Independent model and rule validation

Rules, thresholds and any statistical models should be validated by people who did not build them, with results recorded and findings tracked to closure. The same team that tuned the rules should not be the only team that tests whether they work. Validation must be independent of the build. A partner can help prepare test datasets, backtesting scripts and a validation report template, but the independent reviewer should be your own staff or a party you appoint and document.

Reporting decisions and reporting owners

Decisions on whether to file a suspicious activity report or equivalent report, to whom, and by whom are made by the institution's designated officers. The software can hold the case file and track deadlines, but it should not decide what leaves the institution. Name the reporting officer and the deputy in writing. A partner can help build the case workflow, the audit trail of each decision and the reporting calendar, with the reporting obligations confirmed against your national financial intelligence unit's requirements.

Data licensing for OpenSanctions content

Running yente on your own infrastructure does not by itself settle the terms on which OpenSanctions data may be used. Internal commercial use can require a separate licence, and the answer depends on how your institution uses the data. Confirm the licence scope with the data provider before go-live. A partner can help record which datasets are loaded, when they were refreshed, and where each licence certificate is stored, so the licence position can be shown to a supervisor.

What buyers ask before hiring help with EU AML open source

How much effort does a self-hosted AML monitoring and screening stack take to build?

The effort depends mostly on what the stack must cover, not on the software license, which is free for Jube and yente under their own terms. Effort rises with transaction volume, the number of typologies and rules you must encode, the number of source systems feeding the monitoring, and how much validation evidence your supervisor or internal model validation team expects. A customer-only screening deployment is far smaller than a stack that also covers payments, beneficial ownership and case management. Ask any partner to split its estimate into data integration, rule and model configuration, screening tuning, validation, documentation and handover, so you can see which drivers account for the work.

Which AML costs are one-time and which recur after go-live?

One-time work usually covers architecture, data mapping, integration with core systems, initial rule and screening configuration, validation and the first set of documentation. Recurring costs include refreshing sanctions and PEP list data, applying software upgrades, tuning rules and thresholds as typologies change, reviewing false positive rates, infrastructure operation, and support. Watchlist data licensing is a separate recurring question, so confirm the license terms for internal commercial use with the data provider before you commit. Ask a partner to show these recurring items as separate lines in a written quote, with the party responsible for each.

What must our team provide before an AML implementation can start?

The implementation depends on decisions and inputs that only your institution can make. You need written AML and sanctions policies, a named business owner for risk typologies and thresholds, data owners for customer, account and transaction sources, and case staff who will work alerts and document decisions. Senior decision makers must approve risk appetite, escalation paths and the reporting obligations the stack will support. Without these inputs, a partner can install software but cannot tune it to your risk profile, so agree on these roles and their time commitments in the written scope.

Can a small compliance team run a self-hosted AML stack without outside help?

A small team can operate a mature stack if it has trained staff, clear procedures and someone who owns the infrastructure, but building and validating the initial configuration usually needs specialist skills. Your team will carry alert review, case decisions, periodic rule reviews and evidence collection, which can absorb a large share of a small team's capacity. Before you hire help, ask the partner which tasks it will hand over with training, which it will run under a retainer, how it documents rules and models for examiners, and how it supports your staff after go-live.

How are DeployOpen AML engagements scoped and priced?

DeployOpen works on most engagements under fixed scope, with scope, deliverables and timelines agreed in writing before work starts. The written scope should name the data sources, the monitoring and screening functions, the integrations, the validation activities and the handover items. DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing support, upgrades and continuous testing are available as retainers, which you can scope separately from the initial build. Ask for the assumptions behind each quote, especially those about data quality and the number of rules.

How do we confirm the current status of the EU AML rules and article references?

Check the status of Regulation (EU) 2024/1624 directly in the official EUR-Lex record before you rely on any article reference in a design or a document for supervisors. Confirm the application date and any delegated or implementing measures that AMLA or the European Commission adopt, because those instruments add detail to customer due diligence and monitoring duties. Ask your legal or compliance advisers to confirm which national rules still apply in each Member State where you operate. A partner should map each control to the article and measure it used, and record the date it checked the source so the mapping stays current.

How a self-hosted EU AML rollout is sequenced before 2027

The sequence turns an open-source monitoring and screening stack into a documented, tested system that can be shown to supervisors, with legal scope settled before any configuration starts. Each phase closes with a named output so that the next phase starts from evidence rather than assumptions.

Confirm scope and obligations with counsel
Your legal and compliance team, with external counsel, confirms which entities, products, customer types and jurisdictions fall under Regulation (EU) 2024/1624 and any national rules that still apply alongside it. DeployOpen attends these sessions to translate the outcome into system scope, but does not give legal advice. The client provides the entity map, product list, current AML policy and any supervisory correspondence. The step closes with a signed scope note that lists in-scope systems, data flows and open legal questions, so that later design decisions can be traced back to a stated obligation.
Define requirements and data sources
Working from the scope note, the team writes requirements for customer due diligence data, transaction feeds, monitoring typologies, alert volumes, case handling, retention and reporting. Each sanctions and PEP list source is recorded with its licensing terms, refresh expectations and whether internal commercial use is permitted. The client supplies system inventories, data dictionaries, data protection assessments and the list of internal users. The output is a requirements register and a data source register that name an owner for each feed. Confirm list licensing directly with each provider before this register is approved.
Build the self-hosted environment and data refresh
DeployOpen deploys Jube, yente and their supporting services inside the client's own cloud account, data center or private network, with access control, encryption, logging and backup designed to the client's security standards. A data refresh pipeline is built to load sanctions and PEP datasets on a schedule the client approves, with each load recorded so that the list version in use at any decision can be shown later. The client provides the target environment, identity provider, network approvals and a named administrator. The step closes when a test refresh completes, the version record is written, and a restore test confirms the environment can be rebuilt.
Configure screening and monitoring with documented rationale
The team configures screening thresholds, matching rules, transaction scenarios and any scoring models, and records the reason for each choice against the requirements register. Compliance staff review the initial typologies and set alert routing, case workflows and escalation paths. The client provides historical transaction samples, known typologies from prior investigations and decisions on risk appetite. The output is a configuration baseline and a rationale document for each rule or threshold, with a named approver. Every change after this point goes through the same versioned record, so the reasoning behind the live configuration stays visible to supervisors.
Run parallel testing and validation
The new stack runs alongside the existing process, or against replayed historical data, so that alert quality, match results and processing behavior can be compared before anyone relies on them. The team measures false positive patterns, missed known cases and performance under expected peak load, and documents each finding with a disposition. The client's compliance function signs off on the results and decides which gaps must be fixed before go-live. The output is a validation report with test cases, results, open defects and an approval record. Independent validation can be commissioned separately if the client's model risk policy requires it.
Prepare evidence and runbooks
DeployOpen assembles the control evidence that a supervisor or internal auditor will ask for: access reviews, change logs, list refresh records, configuration rationale, retention settings, backup results and incident procedures. Operating runbooks cover alert triage, case escalation, list updates, outage handling and recovery. The client provides its policies, record retention schedule and names for each control owner. The output is an evidence index that maps each documented control to where its proof is stored, along with runbooks approved by the client. DeployOpen prepares this material but does not issue any audit opinion or certification.
Hand over with a support plan
The client's operations and compliance teams are trained on the runbooks, and the handover covers administration, rule change requests, list refresh monitoring and upgrade procedures. The support model is agreed in writing, including who responds to incidents, how changes are approved and how upgrades are tested before release. The client provides staff for training and confirms its support hours and escalation contacts. The step closes with a signed handover record, a list of open items and a support agreement. Ongoing support, upgrades and continuous testing can be provided under a separate retainer agreed in writing.

How DeployOpen scopes, delivers and supports self-hosted AML

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For EU AML monitoring and screening, we start from a written scope that sets out which obligations the system must evidence before the 2027 application date, then build, test and hand over the system with the records a supervisor would ask to see.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope maps customer due diligence, monitoring and reporting duties to specific system functions and data flows.
We confirm which entity types, customer segments and payment channels fall inside the monitored population and the screening perimeter.

How we build

We deploy Jube and yente inside your cloud accounts, data center or air-gapped network, with the data stores and access paths your policies require.
We configure rules, thresholds and list sources according to the documented risk assessment, and record each parameter choice with its rationale.
We run security testing of the application, APIs and infrastructure before go-live, and we document the findings and fixes.

How we hand over

You receive architecture, configuration, data lineage and runbook documentation written for internal audit and supervisory review.
We prepare the evidence set for the controls in scope, including change records, access logs and model and rule validation notes.
Handover covers administrator training, incident procedures and a tested restore of the system from backup.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing like the initial engagement.
We plan list refreshes, platform upgrades and rule reviews on a schedule agreed with your compliance and IT teams.
Before any change to rules or list sources, we confirm the impact with your compliance function and update the documentation.

Open source AML for the EU Anti-Money Laundering Regulation