Europe’s AML Rulebook Puts Midnight’s Selective-Privacy Model Under Regulatory Scrutiny
Europe’s expanding anti-money-laundering framework is testing whether blockchain networks can protect transaction confidentiality while still giving regulated institutions reliable, verifiable information about customers and funds. Midnight’s zero-knowledge and selective-disclosure model offers one possible answer, but its regulatory credibility will depend on far more than cryptography.
Europe is building a more unified AML perimeter
For years, anti-money-laundering requirements in Europe were shaped by a combination of EU directives, national implementation and supervisory practices that could vary between member states. The latest reform package is intended to make that framework more consistent.
The package includes a directly applicable EU anti-money-laundering regulation, a new anti-money-laundering directive and the creation of the European Anti-Money Laundering Authority, known as AMLA. The measures were adopted in 2024, with important provisions applying over future transition periods. The precise obligations and dates depend on the relevant legal instrument, the type of institution and the applicable national implementation rules.
The policy direction is clear: financial institutions and other obliged entities are expected to identify money-laundering and terrorist-financing risks, apply controls proportionate to those risks, maintain records, cooperate with authorities and report suspicious activity.
The rules are not designed simply to make every financial transaction publicly visible. They are designed to ensure that institutions with access to the financial system can answer basic questions about economic activity:
- Who is the customer?
- Who ultimately owns or controls a company or account?
- Where did the funds come from?
- Where are they going?
- Does the customer or transaction present sanctions, fraud, money-laundering or terrorist-financing risks?
- Can the institution provide relevant information to competent authorities when legally required?
That distinction matters for privacy-preserving blockchain networks. Europe’s debate is not accurately described as a simple choice between total transparency and total secrecy. Increasingly, the question is whether a system can provide trustworthy evidence about compliance without disclosing every transaction, wallet balance and commercial relationship to the public.
AMLA is intended to strengthen cooperation among national financial-intelligence units and supervisors, develop common approaches and eventually exercise direct or indirect supervision over selected high-risk financial institutions. It will not make every blockchain protocol a supervised financial institution. Nor will it automatically decide whether a particular privacy technology is lawful.
Its relevance is institutional. A more coordinated European supervisory structure may make it harder for providers to rely on regulatory gaps between member states. It may also create greater demand for standardized evidence that compliance controls work consistently across borders.
Crypto-asset service providers face closer scrutiny
Crypto-asset service providers, or CASPs, are increasingly treated as part of the regulated financial system. Under the EU’s Markets in Crypto-Assets framework, providers such as exchanges, custodians, trading platforms and other covered businesses must meet licensing and organizational requirements. Their AML obligations arise through the broader European financial-crime framework.
In practical terms, a regulated crypto business may need to perform customer due diligence, verify customers and beneficial owners, assess risk, monitor activity, screen for sanctions exposure, keep records and file suspicious-transaction reports with the relevant financial-intelligence authority.
The EU’s implementation of the Financial Action Task Force’s Travel Rule adds another layer. The Transfer of Funds Regulation, extended to crypto-asset transfers, requires information about the originator and beneficiary to accompany covered transfers handled by crypto-asset service providers. Providers must collect, verify, transmit and retain relevant information according to the applicable rules.
This does not mean that every individual wallet user must publish personal information on a blockchain. It means that regulated intermediaries participating in a transfer must be able to meet information and verification obligations.
Transfers involving self-hosted, unhosted or self-custodied wallets can create additional operational requirements. A CASP may need to collect information about the customer, assess the risk of the external wallet and apply enhanced controls in particular circumstances. The rules do not amount to a universal prohibition on self-hosted wallets.
The distinction between a wallet and a service provider is therefore important. A software wallet used by an individual is not automatically equivalent to a custodial exchange. A decentralized protocol is not automatically equivalent to a licensed CASP. An application that enables regulated exchange or custody may face very different obligations from a person using open-source software without an intermediary.
The legal answer depends on the activity, the entity performing it, the degree of control it exercises and the jurisdiction involved.
At the same time, European rules have shown concern about services that make customers effectively unidentifiable. The AML framework places restrictions and heightened scrutiny around anonymous accounts and arrangements that prevent obliged entities from knowing who is using a financial service. The policy problem is not the existence of encryption or zero-knowledge mathematics. It is the inability to conduct required checks or provide information when lawful authorities need it.
Privacy is not the same as anonymity
The regulatory discussion becomes confused when several different concepts are treated as interchangeable.
A transparent blockchain can expose transaction amounts, addresses and histories to anyone operating a node or using a public explorer. This can make certain forms of monitoring easier, but it can also reveal commercially sensitive information, trading strategies, payroll flows and wallet balances.
A pseudonymous blockchain displays addresses rather than names. The addresses may not be directly linked to real-world identities, but blockchain analysis, exchange records, network metadata and behavioral patterns can sometimes connect them to people or organizations.
An anonymous system is designed to make users, transaction relationships or both difficult to identify. Depending on its architecture, it may conceal not only the public identity of participants but also the ability to link transactions together.
A privacy-preserving or selective-disclosure system takes a different approach. It hides some information by default while allowing a user or authorized party to reveal a defined fact or prove that a condition has been met.
For example, a user might prove that:
- A credential was issued by an approved identity provider.
- The user passed a required eligibility check.
- The user is not included on a particular sanctions list at the time of verification.
- A transaction satisfies a policy without revealing the customer’s full identity to every observer.
- A payment falls within a permitted category or limit.
- A credential is valid and has not expired or been revoked.
A zero-knowledge proof can demonstrate that a statement is true without disclosing all of the information used to establish it. In theory, that could allow a bank, exchange or application to verify a compliance claim while limiting exposure of unrelated financial data.
But cryptographic privacy does not automatically equal regulatory compliance.
A proof can show that a computation was performed correctly according to a defined rule. It cannot, by itself, establish that the identity provider used reliable documents, that a sanctions database was current, that a customer was not coerced, or that a credential issuer is legally accountable.
Those institutional questions are central to Midnight’s prospects.
Midnight’s proposition is selective privacy
Midnight has positioned itself as a privacy-preserving blockchain designed to support data protection, programmable applications and selective disclosure. Its public materials describe the use of zero-knowledge technology and a development environment intended to let applications control what information is disclosed and to whom.
The broad concept is straightforward. A user or application keeps certain data private, then generates a proof showing that a transaction or action satisfies a defined condition. Another party verifies the proof without receiving the entire underlying dataset.
That model differs from treating privacy as an absolute condition. The objective is not necessarily to make all activity unknowable. It is to make disclosure more targeted.
A regulated institution could, for example, want to know that a customer has completed an approved onboarding process without receiving a complete public history of that customer’s unrelated transactions. A business may need to prove that it is authorized to participate in a market without revealing confidential counterparties. A user may want to show that a transfer is eligible under a policy without publishing their balance to competitors.
Whether Midnight can support those scenarios depends on the final design of its applications, credentials, wallets and compliance infrastructure. It is important to separate documented architectural capabilities from assumptions about future integrations.
The presence of zero-knowledge proofs does not prove that Midnight already satisfies the EU AML rulebook. Midnight has not been approved or endorsed by EU regulators merely because its technology uses privacy-enhancing cryptography. Regulatory acceptance would depend on the service being offered, the responsible entities, the controls surrounding it and the evidence presented to supervisors.
The most important questions are operational.
What information is hidden by default? What can be disclosed? Can a disclosure be restricted to one transaction, asset, customer relationship or time period? Who is authorized to request it? Can the recipient independently verify who issued a credential and whether it remains valid? Can an authority obtain information through a lawful process? Can a compliance team investigate suspicious activity when transaction data is not visible on a public explorer?
The answers may not be determined by the base blockchain alone. They may depend on application-level contracts, wallet behavior, identity providers, data custodians and the interfaces connecting the network to regulated institutions.
A proof is only as trustworthy as its inputs
The most significant gap between cryptographic proof and institutional trust lies in the source of the underlying information.
Suppose a user presents a zero-knowledge proof showing that they passed know-your-customer screening. The receiving institution still needs to know:
- Who conducted the screening?
- What documents and databases were used?
- When was the screening completed?
- Was the identity provider subject to appropriate controls?
- Were sanctions, politically exposed person and adverse-media checks included?
- Can the credential be revoked?
- Can the institution determine whether the credential has expired?
- Is the issuer liable if the screening was defective?
A proof can demonstrate that a credential satisfies a mathematical condition. It does not guarantee that the credential reflects reality.
This is a familiar issue in digital identity. Verifiable credentials can improve portability and reduce repeated disclosure, but their value depends on trusted issuers and a framework for determining which issuers are acceptable for which purposes.
Banks and exchanges are unlikely to accept an unfamiliar credential merely because it is technically verifiable. They will need policies governing approved issuers, risk-based reliance, recordkeeping and escalation. Regulators may also ask whether the institution can reconstruct the compliance decision months or years later.
That could require a system to preserve evidence about the credential’s issuer, issuance date, verification event, applicable policy version and status at the time of the transaction. Privacy does not eliminate the need for records. It changes what is recorded, who can see it and how it is accessed.
Revocation is a harder problem than issuance
Issuing a credential is relatively simple compared with maintaining its validity over time.
KYC information can change. A passport can expire. A company can change ownership. A customer can become a politically exposed person. A sanctions designation can be added after a credential was issued. A wallet can be compromised. A service provider can lose its authorization.
A selective-disclosure system must handle those changes without forcing the user to reveal an entire financial history.
Possible mechanisms include revocation registries, short-lived credentials, status checks performed during each transaction and proofs tied to a current compliance snapshot. Each approach involves trade-offs.
Frequent status checks may create metadata showing when a user is transacting. Short-lived credentials can improve security but add operational complexity. Public revocation lists may reveal information about individuals or organizations. Private registries require trusted operators and reliable availability.
The institution receiving a proof must also know what the proof means. Does “not sanctioned” mean that a check was performed against a specified list at a particular time? Does it cover only the customer or also the beneficial owner? Does it apply to the transaction, the wallet, the origin of funds or the destination?
Compliance systems depend on precise definitions. A general statement that a user is “approved” may not be sufficient.
Suspicious-activity monitoring cannot disappear
AML compliance is not limited to onboarding.
A CASP must generally monitor customer activity and investigate unusual behavior. A transaction may be suspicious because of its size, timing, counterparties, geographic exposure, relationship to previous activity or connection to known typologies. The relevant signal may emerge only when multiple transactions are viewed together.
Privacy-preserving systems therefore face a difficult design challenge. If transaction details are hidden from the public but available to an authorized CASP, the model may be compatible with risk-based monitoring. If no responsible party can access sufficient information, investigations could become impractical.
Selective disclosure could allow a provider to request targeted evidence rather than expose every transaction to every observer. A compliance team might receive the information needed for a particular investigation while other users and unrelated counterparties remain excluded.
However, that requires more than a button labeled “disclose.” The system needs procedures for:
- Identifying who may request information.
- Establishing the legal basis for a request.
- Authenticating the requesting party.
- Recording what was disclosed.
- Preventing excessive or unrelated disclosure.
- Preserving evidence for an investigation.
- Responding to court orders or financial-intelligence requests.
- Handling a user who refuses to cooperate.
A user’s refusal to disclose should not necessarily be treated as proof of criminality. But a regulated institution may be unable to proceed with a transaction or relationship if it cannot complete the required checks. Selective privacy does not remove that commercial and legal consequence.
The Travel Rule tests interoperability
The Travel Rule illustrates why a privacy model must work beyond a single blockchain.
A transfer involving two regulated CASPs may require originator and beneficiary information to move between those providers. The transaction itself could remain private on-chain, but the institutions still need a compatible method for exchanging and verifying required data.
That creates an interoperability problem. Wallets, exchanges, banks, custodians and applications may use different credential formats, identity providers and compliance vendors. A privacy system that works only within one ecosystem may not satisfy an institution operating across several networks.
The problem becomes more complicated when a transfer involves a self-hosted wallet. The CASP may need to identify its own customer, assess the destination and apply risk-based controls. It may also need to determine whether the wallet is controlled by the customer or another party.
A selective-disclosure model could potentially help a user prove control of a wallet or present a compliance credential without broadcasting their identity to the entire network. But the receiving institution would still need to trust the proof, understand its scope and determine whether it satisfies the applicable Travel Rule process.
This is where standards will matter. Adoption may depend less on whether one project has an elegant privacy design and more on whether multiple providers can exchange evidence in a common, auditable format.
Privacy can reduce risk, but also create new risks
The case for selective disclosure is not only ideological.
Public blockchains can expose information that traditional financial systems generally keep within a restricted network of institutions. A company’s wallet activity may reveal supplier relationships, treasury decisions or trading strategies. An individual’s transaction history may reveal salary payments, donations, medical expenses or associations.
Data minimization is also a core principle of European privacy law. Sharing only the information needed for a specific purpose can reduce the damage caused by breaches, misuse and unnecessary profiling.
Selective disclosure could support that principle by allowing an institution to verify a narrow claim rather than collect and retain an entire identity file. It could also reduce the number of parties that can map a person’s blockchain activity.
But privacy systems have their own attack surfaces.
Credential theft could allow an attacker to present someone else’s compliance status. Metadata may reveal when a user interacted with a compliance provider. Timing, transaction size, network connections and repeated behavioral patterns can permit reconstruction even where transaction contents are hidden.
A supposedly private system may also leak information through application interfaces, wallet telemetry, centralized relayers or poorly designed smart contracts. Privacy at the ledger layer cannot compensate for an application that sends a user’s identity and transaction history to an analytics provider.
Regulators and financial institutions will therefore assess the entire control environment, not just the zero-knowledge circuit.
Governance determines who can answer regulators
A decentralized architecture does not eliminate accountability.
If an application facilitates regulated custody, exchange or payment services, authorities will want to know which legal entity is responsible. If a credential issuer makes an error, someone must be able to investigate and correct it. If a court orders disclosure, someone must determine how to respond. If the network’s compliance rules change, someone must manage the update process.
These questions can be uncomfortable for projects that emphasize decentralization. Yet they are unavoidable where a system interacts with regulated finance.
Potential accountability points include:
- The CASP or financial institution serving the customer.
- The wallet provider or application operator.
- The identity or credential issuer.
- The infrastructure provider hosting compliance services.
- The developer or entity controlling an upgrade mechanism.
- The organization responsible for maintaining a revocation or status registry.
The answer may vary by use case. A public blockchain network may not be directly responsible for every application built on it. But regulated entities using the network will still need to map responsibilities and demonstrate that failures can be detected and managed.
A regulator may also ask whether the network’s rules can be changed quickly enough to address new sanctions, fraud patterns or legal requirements. A system that cannot be updated may become obsolete. A system that can be changed unilaterally may raise governance and trust concerns.
The practical test will happen at the institutional edges
Midnight’s long-term regulatory case will be tested where the blockchain meets existing financial infrastructure.
An exchange may need to onboard a customer, verify a credential, screen a wallet, monitor transactions and file a suspicious-activity report using tools already integrated into its compliance platform. A bank may require predictable performance, access controls, support procedures and a contractual counterparty. A custodian may need to prove that it can segregate customer assets and maintain records.
For selective privacy to be useful, the technology must meet operational requirements.
Interoperability
The system must work with identity providers, Travel Rule vendors, blockchain analytics systems, custody platforms and regulatory reporting tools. A closed model could limit adoption even if it performs well technically.
Speed and reliability
Proof generation and verification must be fast enough for onboarding, payments and trading. Institutions will also care about uptime, predictable costs, key management, incident response and the ability to process large volumes.
Auditability
A compliance officer should be able to determine what was proved, under which policy, when the proof was generated, who issued the credential and whether the credential was valid at the time. Auditors and regulators may need to review that evidence later without turning all user activity into public data.
Data security
Private information may be held off-chain, in wallets or by credential providers. Each storage point creates risks involving theft, loss, unauthorized access and service outages. The system must define how users recover credentials and how institutions respond when keys are compromised.
Legal process
A regulated provider must be able to respond to lawful requests. That does not necessarily require a universal back door or unrestricted access to every transaction. It does require a clear process for identifying the relevant information, authenticating the request and preserving due process.
Customer support
Users who lose keys, fail a status check or discover that a credential has been revoked will need an understandable process for correction and appeal. Compliance systems that work only for technically sophisticated users may struggle to serve mainstream customers.
Three competing models remain in the market
Europe’s policy debate can be understood as a contest among three broad models.
The first is full transparency. It gives institutions and analysts extensive visibility into transaction flows. Monitoring may be easier, but users and businesses can lose confidentiality. Public data can expose commercially sensitive activity and create long-term privacy risks.
The second is full anonymity. It can protect users from surveillance and transaction tracing, but it creates serious problems for institutions that must identify customers, assess risks and investigate suspicious activity. It is difficult to reconcile with regulated financial services where no accountable intermediary can provide required information.
The third is selective disclosure. It attempts to keep unrelated information private while making specific compliance facts provable to authorized parties.
Selective disclosure is attractive because it resembles the way many traditional systems already operate. A bank does not normally publish every customer record on a public website. It retains information, limits access and provides it to authorities under defined conditions.
The difference is that blockchain systems can make those access rules programmable and potentially portable across institutions. A user may be able to prove a claim without repeatedly sending the same documents to every service provider.
That promise also creates a new dependency on the quality of digital credentials, verification standards and governance arrangements.
Europe’s policy may favor compliance infrastructure
One likely consequence of the new AML environment is that compliance infrastructure becomes a competitive differentiator.
Large exchanges, banks and custodians already have compliance teams, transaction-monitoring systems and relationships with identity providers. They may be able to integrate privacy-preserving credentials more easily than small applications or loosely coordinated decentralized projects.
Smaller providers could face the cost of building controls for onboarding, sanctions screening, monitoring, recordkeeping, Travel Rule messaging and incident response. Even if the underlying blockchain is open, access to regulated markets may depend on a substantial layer of centralized compliance infrastructure.
This could produce an uneven market. Privacy-preserving networks that offer clear integration paths and recognized credential standards may attract institutional users. Projects that provide technical privacy without a credible compliance operating model may face delistings, restricted access or limited banking relationships.
The experience of privacy coins and privacy-enhancing tools in several markets shows the commercial risk. Exchanges have delisted or restricted assets when they could not obtain sufficient information about transactions or users, even where the technology itself was not universally prohibited.
The same pressure could affect applications built on privacy-preserving networks. A provider may decide that supporting a private asset or transaction type creates too much uncertainty for its licensing, banking or reporting obligations.
Zero-knowledge technology is spreading beyond transaction privacy
The significance of Midnight does not depend solely on whether its network becomes a major venue for private payments.
Zero-knowledge technology is being explored in scaling, identity, payments, voting, supply chains and compliance. In each case, the goal is to prove a result without exposing all the data used to produce it.
That makes the technology relevant to the EU’s broader digital agenda. Selective disclosure intersects with digital identity, verifiable credentials, data protection, central-bank digital currency design and regulated digital assets.
A digital euro or other future payment system, for example, could raise similar questions about how to preserve user confidentiality while meeting financial-crime obligations. A credential system used across multiple financial networks could reduce repeated collection of personal data, provided that institutions can trust issuers and verify status.
The technical model is therefore likely to remain important even if any individual blockchain project does not achieve widespread adoption.
What regulators would need to see
For Midnight or a similar network to gain credibility with European institutions, broad claims about privacy would not be enough. Regulators and compliance professionals would likely look for evidence in several areas.
First, the system would need documented technical specifications, independent security assessments and clear explanations of what information is hidden, retained or disclosed.
Second, there would need to be credible identity and credential arrangements. Institutions would need to know which issuers are acceptable, how they perform KYC and sanctions checks, and how their credentials are revoked or corrected.
Third, providers would need to demonstrate that proofs can be generated and verified reliably at realistic transaction volumes. Performance data, incident records and operational testing would be more persuasive than theoretical capability.
Fourth, the system would need to integrate with existing compliance processes. That includes Travel Rule messaging, transaction-monitoring systems, case-management tools, audit records and suspicious-transaction reporting.
Fifth, legal responsibility would need to be clear. A regulated institution cannot outsource accountability to mathematics. It must know which parties are responsible for identity errors, compromised credentials, faulty status information and network failures.
Sixth, authorities would need a workable method for obtaining information during investigations. That method should be targeted and legally controlled, but it must be practical enough to support financial-intelligence work.
Finally, there would need to be evidence from real deployments. Pilot programs with regulated institutions, integration by exchanges and custodians, independent audits and recognition by compliance professionals would provide stronger signals than marketing language.
The unanswered questions are decisive
Midnight’s model raises questions that its technology alone cannot settle.
Can a user prove that they passed KYC without revealing their full identity on-chain? Potentially, if the relevant application and credential system support that use case. But a regulated institution would still need to assess the issuer and retain sufficient evidence.
Can a bank independently verify the issuer and validity of a credential? Only if the ecosystem provides trusted issuer registries, status mechanisms and interoperable verification standards.
Can disclosures be limited to a specific transaction, asset or period? That is a design question for the relevant credential and application. It should not be assumed merely because the network uses zero-knowledge proofs.
What happens when a user refuses disclosure? A provider may be unable to complete onboarding or execute a transaction. Privacy technology does not create a right to receive regulated services without satisfying applicable controls.
How can suspicious transactions be investigated? The system must give the responsible institution enough visibility, either through transaction-level permissions, user-provided disclosures, trusted intermediaries or another authorized process.
What happens when a private transaction interacts with a transparent chain, exchange or bank? The privacy boundary may weaken at the point of conversion or interaction. The institution may obtain identifying information, and blockchain analytics may connect the private activity to public addresses or accounts.
These are not reasons to reject selective privacy. They are the conditions under which its claims must be tested.
Success would mean controlled transparency
The strongest version of Midnight’s proposition is not that regulators should accept unknown users and invisible money. It is that regulated institutions should be able to verify relevant facts without collecting or publishing more information than necessary.
That would represent a shift from universal visibility to controlled transparency.
Success could be measured by whether:
- Exchanges and custodians integrate the system into ordinary compliance workflows.
- Independent security audits support the privacy and proof mechanisms.
- Proof generation and verification meet production performance requirements.
- Credential issuance, expiration and revocation work across providers.
- Institutions can document compliance decisions for auditors and supervisors.
- Regulated users can respond to lawful information requests without exposing unrelated activity.
- The system interoperates with Travel Rule and transaction-monitoring tools.
- Clear legal responsibility exists when controls fail.
- Compliance professionals and regulators recognize the evidence as usable, not merely mathematically valid.
No single technical feature will answer all of those questions.
A zero-knowledge proof may reduce unnecessary disclosure. It may help separate a customer’s identity from the public transaction graph. It may make it possible to verify eligibility without publishing a complete balance or history.
But it does not replace KYC. It does not replace sanctions screening. It does not replace suspicious-activity monitoring. It does not determine whether an identity provider is trustworthy. And it does not decide who must cooperate with authorities.
Europe is testing whether privacy can become a control
The EU’s AML reforms are likely to make the operating environment more demanding for crypto businesses, but they do not necessarily close the door on privacy-preserving networks.
The framework leaves room for risk-based controls and does not impose a universal ban on self-hosted wallets, zero-knowledge proofs or all private blockchain transactions. The pressure is directed at regulated activity that cannot identify customers, assess risk, trace relevant transfers or provide required information.
That creates a possible opening for selective disclosure.
Midnight’s architecture represents a broader regulatory and technical experiment: whether privacy can be designed as a controlled compliance feature rather than treated as an obstacle to oversight. Its success will depend on proving not only that data can be hidden, but that the right data can be made verifiable, trustworthy, accessible to authorized parties and usable within existing financial-control systems.
If that infrastructure works, selective privacy could offer a middle path between public exposure and unaccountable anonymity. If it does not, institutions may continue to prefer transparent networks because they are easier to monitor, investigate and explain to regulators.
For Midnight, the decisive test will not be whether it can conceal a transaction. It will be whether a bank, exchange, auditor or financial-intelligence authority can obtain enough reliable evidence to understand the transaction when it matters, without turning every legitimate user’s financial life into public information.
Regulatory note: The EU AML package, AMLA framework and crypto-asset transfer rules include different application dates, transitional arrangements and obligations depending on the entity and activity. Midnight’s technical capabilities and compliance integrations may also evolve. Nothing in this article should be read as an indication that Midnight has been approved or endorsed by EU regulators.