When Journalists Have Better AML Tools

Aleph, OCCRP’s data platform, is no regulatory panacea. But it exposes an uncomfortable truth: much of what banks struggle with in anti-money laundering is not a knowledge problem. It is an architecture problem — and nowhere is this more evident than in the KYC chain.

In Amsterdam, there is no bank, no compliance apparatus, and no regulatory authority. And yet the Organized Crime and Corruption Reporting Project — OCCRP for short — operates from there a platform that has long become a kind of shadow standard for investigative financial research in professional circles. The platform is called Aleph. In its latest iteration, Aleph Pro, it processes more than 4.4 billion entities according to OCCRP.¹ OCCRP itself puts the impact of its investigations at over eleven billion dollars in fines and seized assets since 2009.²

What is remarkable about Aleph is not that journalists built a useful tool. That happens. What is remarkable is that a non-profit organization, in terms of data model, linking logic, and research ergonomics, often works closer to the operational reality of transnational financial crime than some regulated major banks with six- to seven-figure license budgets for AML software.

Although the comparison, let it be said right away, is only partially fair. OCCRP is not subject to regulation, does not have to protect customer data, does not have to fulfill supervisory documentation obligations, and can work with leaked datasets that are off-limits for institutions. Anyone who equates regulated compliance with investigative journalism is comparing two systems with fundamentally different legal and operational constraints. Nevertheless, the architectural comparison is worthwhile. Not because banks should adopt Aleph, but because the design decisions behind Aleph illuminate the weaknesses of common compliance architectures with uncomfortable clarity. And nowhere is this more evident than in the KYC process.

¹ OCCRP Annual Report 2024: „4.4B+ entities in OCCRP Aleph.“ The figure refers to the entire OCCRP instance, not to individual Aleph Pro deployments. ² OCCRP About page, period 2009–2024: „$11 billion+ in fines levied and monies seized.“ The attribution includes cases to which OCCRP investigations contributed.

Aleph is built on FollowTheMoney (FtM), an open ontology for investigative data. Persons, companies, ownership structures, payment flows — everything is modeled as a typed entity with multi-valued properties. The schema exports to CSV, Excel, and Cypher, the query language of the graph database Neo4j.³ A journalist in Bucharest and a researcher in Nairobi work with the same data structure. That sounds trivial. In the regulated world, it is the exception.

Because there, fragmented diversity reigns. Every vendor — whether Actimize, Norkom, Fircosoft, or the various proprietary developments — defines its own entity structure. Those who migrate lose context. Those who integrate build mapping tables that become outdated after the first project manager change. Interoperability, the declared goal of European AML harmonization, has so far barely materialized at the data model level.

³ FollowTheMoney documentation, followthemoney.tech; Cypher and CSV export documented. ⁴ Cf. GitHub: alephdata/followthemoney-compare. ⁵ OCCRP About page: „1,000+ sources from 180+ countries.“ The figure refers to source registers and datasets, not to Aleph entities themselves. ⁶ OCCRP Aleph Pro FAQ, June 2025.

Entity matching deserves a closer look. Aleph’s cross-referencing uses an ML model that automatically down-weights frequent tokens — common surnames, generic company suffixes — and up-weights rare identifiers. The result is probabilistic matching that recognizes fuzzy variants without flooding the alert queue with obvious false hits. In many screening systems of regulated institutions, the opposite happens: rule-based matching generates high alert volumes that analysts must work through individually. How high the proportion of irrelevant hits is varies by institution and calibration — but that the effort for manual disposition is a central cost driver is something hardly anyone in the industry disputes.

Anyone who wants to dismiss the comparison between Aleph and regulated systems as academic should look at the KYC chain. This is where the architectural difference becomes operationally tangible.

Know Your Customer, in its classic form, is a periodic process. A customer is reviewed when the business relationship is established. After that, depending on the risk classification, they are reviewed again every one to three years — the so-called KYC refresh. Between review cycles, if we are being honest, little systematic happens. If a customer’s ownership structure changes, a new beneficial owner appears, a sanction is imposed, or a PEP status becomes relevant, the institution learns about it in the best case through transaction monitoring, in the worst case at the next scheduled review — months or years later.

The industry knows this is not enough. The buzzword is perpetual KYC — pKYC: the replacement of periodic review cycles with continuous, event-driven monitoring of the business relationship. In principle, the institution no longer monitors at fixed intervals but reacts to relevant changes as they occur: a new sanctions listing, a change in the UBO structure, an adverse media hit, a shift in transaction dynamics.

In principle. In practice, pKYC fails due to the same architectural problems that plague the rest of the AML chain. Because event-driven KYC monitoring requires three things: first, a data model that can natively map relationships between entities — not as rows in a table, but as a graph. Second, a mechanism that automatically propagates changes to one entity to all linked entities. Third, a data foundation that extends beyond the institution’s own customer base and continuously incorporates external sources — registers, sanctions lists, PEP databases, adverse media.

Aleph meets all three prerequisites — not because it was built as a KYC system, but because its architecture relies on precisely those principles that would technically enable pKYC. FollowTheMoney models relationships as separate entities with timestamps and confidence scores. Aleph’s indexing is designed to detect changes in source data and reprocess them. And the data foundation encompasses over a thousand external sources that are regularly updated.

One should not overstate this finding. Aleph is not GDPR-compliant, not audit-proof in the sense of MaRisk, and not designed as a production system for KYC obligations under the GwG. Maltego rightly points out that the data must be independently verified and does not constitute a standalone KYC solution.⁷ And the operational requirements for a production pKYC system — audit trail, four-eyes principle, regulatory reporting capability, client segregation — go far beyond what Aleph offers or intends to offer.

But it remains an instructive contrast: a journalism platform has been working for years with precisely those architectural principles — graph-native data models, event-based updating, confidence-weighted linking — that the regulated world discusses as a future vision under the label pKYC. The difference is not in the understanding of what is needed. The difference is in who built it.

⁷ Maltego Transform Hub, OCCRP Aleph Integration: Aleph data does not constitute a standalone KYC solution for regulated industries.

Here the story gets peculiar. OpenSanctions, the open sanctions and PEP database that a growing number of institutions use to supplement commercial lists, is natively built on the FollowTheMoney data model. Every entity — person, company, ownership structure — is an FtM object with schema, properties, timestamps, and dataset references. Yente, too, the matching API of OpenSanctions, expects and delivers FtM structures.⁸

Institutions that consume OpenSanctions or yente-based screening services are therefore working with FtM data — often without being aware of it. What happens next is instructive: most ingest pipelines transform the FtM entity into a proprietary format. The graph structure is dissolved. Metadata about data provenance and timestamps is degraded. What starts as a linked data object ends up as a row in a relational table.

Now, this transformation has reasons that must be taken seriously. Data protection demands controlled data management, not associative graphs. Supervisory audits expect traceable, documented processes, not dynamic knowledge graphs whose state changes between two audit dates. And existing core banking systems are simply built on relational foundations — you cannot rebuild every architecture overnight.

All of this is true, and an honest comparison must account for it. But it remains a remarkable finding that the open, investigative ecosystem has produced a data model optimized for linking and context preservation — while the regulated world consumes models optimized for control and isolation. Both design principles have their justification. The question of which is better suited to detecting transnational networks is less clear-cut than purists on either side would like — but it deserves a more honest debate than has been conducted so far.

⁸ OpenSanctions Technical Documentation: Entity structure is based on FtM; cf. opensanctions.org/docs/entities/.

AMLA, the new EU Anti-Money Laundering Authority headquartered in Frankfurt, is supposed to bring harmonization. Its Regulatory Technical Standards are meant to ensure that institutions across Europe work according to comparable standards. The drafts presuppose a remarkable granularity and imply extensive comparability of data fields — from identification attributes to UBO structures to risk assessments.⁹

On paper, this is ambitious. In practice, harmonization hits a limit that neither AMLA nor the accompanying regulation addresses: there is no common data model. Every institution models its customers, transactions, and risk assessments differently. Every vendor structures its alerts and KYC dossiers differently. Standards can be defined — as long as the underlying data models are not compatible, harmonization remains a documentation promise.

FollowTheMoney is not a ready-made solution for this problem. It was developed for investigative journalism, not for KYC processes with their specific requirements for data protection, audit compliance, and supervisory documentation. But the design principle — an open, typed, graph-capable ontology with clear schema definitions — is more relevant as a conceptual model for the harmonization debate than the industry has been willing to acknowledge so far.

Aleph Pro makes the discussion even more interesting: the platform introduces confidence labels on connections — a quantified assessment of how reliable the relationship between two entities is. For experienced compliance practitioners, this is self-evident: a PEP match on a common name does not carry the same weight as a full hit with matching date of birth, address, and nationality. But most screening systems do not systematically represent this distinction. The alert is binary: triggered or not. For KYC refresh and pKYC, this is a particularly costly weakness because every binary alert triggers a manual review cycle — precisely the process that pKYC is supposed to automate.

⁹ Cf. AMLA RTS consultation documents; the EBA has transferred the institutional framework for RTS development to AMLA.

Something is shifting — not dramatically, but steadily. The boundaries between investigative journalism and regulated compliance are blurring at the technical edges. Aleph Pro is going commercial: SaaS from mid-2026, enterprise tier with on-premise deployment, direct outreach to existing instance operators. Over 60 organizations worldwide were running their own Aleph instances; they are now being migrated to the new stack.¹⁰ This is no longer a niche tool. This is infrastructure with a business model.

OpenSanctions is steadily gaining acceptance in the regulated world. FollowTheMoney exports to Cypher, the language of Neo4j — the graph database increasingly used in the financial industry for fraud detection and network analysis. The pKYC debate generates demand for precisely the architectural principles that the open-source ecosystem has been delivering for years. The tools are converging. The question is whether demand will follow.

So far, little suggests the established players are moving. The vendor contracts are running. The refresh cycles are ticking. The manual reviews are piling up. And in Amsterdam, meanwhile, the next billion entities are being indexed.

This is not an indictment. It is a stocktaking. And viewed soberly, it comes down to this: the regulated financial world has an architecture problem that cannot be solved with license budgets alone — and one that is becoming sharper, not milder, with pKYC requirements. The open-source ecosystem shows how open data models, probabilistic matching, and graph-based analysis can work together. The regulated world knows these tools. Whether it learns from them or continues to invest in extending existing contracts is not a technical question. It is a question of institutional inertia — and eventually, inevitably, a question for the supervisors.

¹⁰ OCCRP Aleph Pro FAQ: „more than 60 organizations around the world are running their own instances.“