Wallets as the New Compliance Layer

On March 16, 2026, the French Treasury (DG Trésor) and the ACPR published updated joint guidelines on the implementation of asset-freezing measures. The text is formally “explanatory” rather than binding in itself, but that should not mislead anyone. Its purpose is to remove ambiguity around how financial institutions, payment providers, and crypto-asset service providers are expected to implement sanctions-related asset freezes in practice. This is not a narrow compliance memo, it’s a blueprint for how regulated financial systems are now expected to behave.

For years, many firms treated sanctions implementation as a screening layer attached to onboarding or transaction monitoring. That model is no longer sufficient. The French guidelines make explicit that asset freezing is not a periodic control, not a paperwork exercise, and not a simple vendor integration. It is an execution obligation that must sit inside the operational core of the institution. In other words, if you touch the movement, custody, authorization, or release of value, you are now part of the sanctions enforcement chain.

That matters especially for digital assets. Wallet infrastructure is often described as technical plumbing: key management, signing, policy enforcement, transaction orchestration. The French framework makes clear that this plumbing is now regulatory infrastructure as well. A modern wallet stack is no longer just a way to sign transactions securely. It has become a control surface through which regulated institutions are expected to satisfy hard legal obligations. The guidelines themselves are here.

What the French regulator is actually trying to do

The first thing the French authorities are doing is drawing a sharp line between asset freezing and the broader AML world. The new guidelines state that the implementation of asset-freezing measures is an obligation of result, and not a risk-based obligation comparable to ordinary AML controls. That’s a decisive distinction. AML programs are based on judgment, calibration, proportionality, and ongoing risk management. Asset freezing is different. If a designated person or entity is involved, the institution must freeze the relevant assets and prevent prohibited funds or resources from being made available. Failure to do so is not a weak process outcome. It is a compliance breach that can trigger administrative and criminal consequences.

The regulator is also clarifying that these obligations begin as soon as the relevant measures enter into force. For national French measures, that can be the publication of an arrêté in the “Journal officiel.” For EU measures, it is the entry into force of the relevant regulation. For certain UN-based designations, French law is designed to bridge the gap and apply them without delay through the national register, even before the corresponding EU implementing regulation is adopted, for up to ten working days. That is a crucial operational point. Firms cannot hide behind process lag, internal approval cycles, or the time it takes different legal layers to catch up. The state has explicitly designed the regime to minimize any implementation gap.

This is also why the guidelines insist so heavily on speed. The institution must act “without delay,” and the reporting to DG Trésor must be “immediate.” The document even references prior ACPR sanctions decisions to underline that processing alerts over several days or several weeks is incompatible with the required speed of implementation. In other words, sanctions controls that are technically correct but operationally slow may still be non-compliant.

The second thing the regulator is doing is expanding how firms should think about the object being controlled. The text reminds institutions that the notion of “funds” and “economic resources” is intentionally broad. It covers classic accounts and securities, but also claims, guarantees, insurance-related assets, stored value, and crypto-assets. Crypto is not treated as some marginal special case outside the sanctions perimeter. It is plainly inside it. More precisely, the guidelines state that resources économiques include crypto-assets falling within MiCA’s scope, other than e-money tokens, and that financial institutions must freeze those resources when they are depositaries of them or otherwise hold them in custody.

The third thing the regulator is doing is broadening the notion of exposure. The obligation is not limited to assets formally owned by a designated person. It also extends to situations where funds or resources are held, controlled, or made available to them, directly or indirectly. This is where the text becomes much more sophisticated than many sanctions implementations found in market practice. The true compliance question is not just “Is the customer on a list?” The question is whether the institution’s systems might allow value to reach, remain accessible to, or be used for the benefit of a designated person through indirect channels, family structures, intermediaries, or transaction patterns that amount to circumvention.

That is why the document is so explicit about circumvention. It does not just require list matching. It requires institutions to build the capacity to detect attempts to evade the measure, including indirect availability of funds and suspicious changes in payment flows. The examples in the text are revealing: salary flows redirected to a spouse, new accounts opened by close family members shortly after a freeze, or payment rerouting that preserves practical access to the frozen value. These examples show the regulator’s real concern. It is not satisfied with superficial blocking. It wants institutions to ensure that the measure actually works in substance.

Why this matters especially for digital assets and wallet technology

The guidelines do not relegate crypto to a footnote. On the contrary, they make crypto-asset service providers part of the main story. The text expressly states that PSCA and, during the transition period, PSAN providing crypto-asset services, should filter all transfers of crypto-assets before making them available to the beneficiary, whether those transfers occur in the context of an ongoing business relationship or as occasional transactions. That sentence alone has far-reaching implications. It means that in crypto, compliance is expected to happen in the transaction path itself, and before finalization, not as a retrospective review.

The guidelines then go further. They say that all parties to crypto-asset transfers should be screened, and that institutions should use all relevant information available under the Travel Rule framework in Regulation (EU) 2023/1113, including the purpose of the transfer, the details of intermediary CASPs, and even the wallet addresses of the originator and beneficiary when official sanctions-linked wallet address lists are available. The text also notes that where appropriate given transfer volume and count, CASPs should integrate blockchain analysis into their transaction-monitoring framework. That is an important signal. The regulator is telling the market that sanctions compliance in crypto is not just a name-screening problem. It is also a data-model and transaction-context problem.

Even more concretely, the guidelines state that CASPs should prevent outgoing crypto transfers from the wallets of designated persons, and may need to use a waiting wallet or similar operational arrangement to ensure that the freeze is effectively enforced. This is a very operational instruction. It acknowledges that the actual mechanics of wallet management matter. Freezing in crypto is not just a database flag. It requires transaction controls, wallet-state controls, and an execution model capable of stopping outflows before they happen. This is why wallet infrastructure is no longer merely a technical dependency. It becomes a critical regulatory control point.

Infrastructure must play the role of a compliance forcing function

The most important shift in the French framework is not that it adds yet another sanctions reminder. It is that it turns infrastructure into part of the enforcement architecture.

The document requires regulated firms to implement written internal procedures, sufficient human and technical resources, staff training, dedicated internal controls, group-level consistency, alert handling, escalation, and immediate declarations to DG Trésor. It also expects firms to cover both the “stock” and the “flows,” meaning both their customer base and their transaction activity. It expects the institution to be able to detect designated persons, prohibited operations, circumvention attempts, and operational failures in its own controls.

This has a profound technical consequence. If your wallet layer creates, signs, authorizes, schedules, or broadcasts transactions, then it sits exactly where the regulator needs enforcement to happen. In the old mental model, wallets were security infrastructure and sanctions lived somewhere else. In the new model, wallet infrastructure becomes one of the places where sanctions obligations are either made real or made ineffective. So the wallet layer becomes, in practice, a screening engine, a policy enforcement system, and an audit and reporting surface.

Why this will likely spread across the EU, the UK, and beyond

The French text is national, but its foundations are not. The guidelines explicitly sit at the intersection of UN sanctions mechanisms, EU restrictive measures, the French Monetary and Financial Code, FATF recommendations, and EBA guidelines from late 2024 on internal controls for restrictive measures and for transfers under Regulation 2023/1113. The document is therefore not an isolated French innovation. It is a French operationalization of a broader international direction.

Within the EU, convergence is the most likely scenario. The logic is straightforward. The legal source of many of these obligations is already European, and the guidelines expressly integrate EBA guidance. Once one major regulator articulates a detailed operating model for payment providers and CASPs, other supervisors do not need to invent a new one from scratch. They can move toward similar expectations around immediacy, internal controls, alert handling, Travel Rule data usage, transaction-path filtering, and treatment of indirect exposure. That is especially true because the French document already frames its expectations in the language of EU regulations and EBA standards.

For the UK, one should be careful not to claim direct legal harmonization where it does not exist. But as a matter of supervisory logic, the direction is similar. The UK sanctions framework also depends on effective implementation rather than merely formal policies, and the broader international trend is toward faster, more operationally embedded control systems. The French text is therefore best seen as a preview of the kind of technical articulation other major jurisdictions may increasingly expect, whether by formal guidance or through examinations and enforcement.

Switzerland is in a similar position. It is outside the EU, but deeply connected to European financial flows and historically attentive to cross-border sanctions implementation. The specific French concepts of immediate action, broad definitions of assets, control over indirect availability of funds, and the need for effective organizational controls are not uniquely French problems. They are features of how any modern sanctions regime increasingly has to function once digital assets, APIs, instant payments, and multi-jurisdictional financial stacks enter the picture.

Even beyond Europe, the same pattern is emerging for a simpler reason: FATF Recommendation 6 and Recommendation 7 do not tolerate leisurely or symbolic enforcement. They point toward real implementation of freezing measures relating to terrorism financing and proliferation. The French text repeatedly anchors itself in that international logic.

So the right conclusion is not that every jurisdiction will copy this document paragraph by paragraph. It is that France has now made explicit what many regulators elsewhere are moving toward implicitly: sanctions enforcement must be immediate, systematized, evidenced, and embedded into the execution path.

What fintechs and financial institutions should expect internally

The practical implication for companies is that sanctions can no longer be treated as a narrow compliance workstream owned in isolation by legal or operations.

The first question is governance. Every institution should now ask, very concretely, who owns the asset-freezing control plane. If the answer is “compliance” but engineering owns the transaction rails, product owns the approval flows, and operations owns exception handling, then no one really owns the end-to-end outcome. Under a regime based on an obligation of result, that fragmentation is dangerous. Someone must own the system as a system.

The second question is about where enforcement actually occurs. Many companies still discover sanctions issues too late in the flow. They screen at onboarding, perhaps re-screen periodically, and then rely on transaction monitoring to catch suspicious movements after the transaction has already been initiated or, in crypto, after the transfer has been irrevocably signed and broadcast. That is not the architecture this framework rewards. Institutions should ask whether their stack can stop a prohibited transfer before execution, whether it can block an outbound crypto transfer from a frozen wallet, whether it can screen beneficiary-side transfers before making them available, and whether it can do so in real time.

The third question is about data sufficiency. The guidelines make clear that screening should not be limited to a shallow name match. Institutions should ask whether they can screen aliases, multiple identifiers, corporate data, beneficial relationships, Travel Rule data, intermediary details, and wallet addresses where relevant. They should ask whether newly obtained information is fed back into the alert analysis process, as the guidelines expect. If the answer is no, the firm may have a sanctions tool but still not have a sanctions system.

The fourth question concerns circumvention. Firms need to ask whether their control framework can spot not just the designated person, but the practical workarounds around that person: rerouted payments, proxy accounts, related entities, or sudden changes in transaction patterns that preserve access to funds indirectly. This is often where institutions overestimate their readiness. They think sanctions is about filtering names against a list. The French text makes clear that the real test is whether the institution can prevent effective access to value.

The fifth question is about operating models and control evidence. The guidelines require written procedures, staff training, internal control, annual or more frequent review of the firm’s exposure to restrictive measures, and group-level governance. They also make clear that asking customers to self-certify that they are not designated is not enough. Nor is outsourcing the problem. If external providers are involved in filtering, list management, or alert handling, the regulated institution remains responsible and must control those providers within its own permanent and periodic control framework.

The sixth question is reporting readiness. Firms must ask whether they can provide evidence when they detected the issue, when they froze the assets, when they stopped the transfer, and when they informed DG Trésor. In high-pressure environments, institutions often discover that they have logs, but not decision-grade audit evidence. The French framework is implicitly asking for more than generic observability. It is asking for compliance-grade traceability.

The do’s and don’ts companies should take seriously

What should companies do? They should treat sanctions implementation as a production system, not a legal appendix. They should build or adopt infrastructure that places screening and policy evaluation before final transaction execution. They should map the entire path from detection to freeze to reporting, identify every dependency that creates latency, and remove manual bottlenecks that undermine “without delay” enforcement. They should review whether their onboarding, transaction flows, wallet controls, Travel Rule ingestion, alert handling, escalation, and audit trail work as a coherent system rather than as separate tools. They should document ownership and test failure scenarios, not just happy paths. And they should revisit their group operating model, especially where branches, subsidiaries, and cross-border services are involved, because the French text expressly deals with group-level internal control and the extension of obligations beyond a single domestic entity.

What should they avoid? They should avoid assuming that “best effort” is a defense. They should avoid relying on screening that happens after execution. They should avoid building fragmented stacks where one vendor screens names, another manages case handling, another controls payments, and no one owns the combined latency and failure modes. They should avoid assuming that delegated access or family relationships are outside the compliance perimeter. They should avoid treating sanctions controls as static, because the guidelines expressly require written methodologies and periodic review of the institution’s exposure to restrictive measures. And they should avoid believing that outsourcing filtering transfers responsibility. The regulator is clear: externalization does not externalize accountability.

Why this pushes the market to rethink wallet infrastructure

This is the point the market still underestimates. Many institutions have spent the last few years assembling digital-asset infrastructure the same way they assemble other enterprise stacks: one provider for custody or MPC, one for screening, one for AML, one for Travel Rule, one for approvals, one for observability, and internal glue code in between. That approach can work for experimentation. It becomes much harder to justify once the regulator expects immediate, deterministic, end-to-end enforcement in the execution path.

The more components are stitched together, the more failure modes appear. Screening can happen too late. Address intelligence may not make it into policy logic. Case decisions may not propagate to the wallet or transaction builder fast enough. One system may know the counterparty is problematic while another still signs the transfer. That is precisely the kind of operational fragmentation that these guidelines make less tolerable. This is why the market should start distinguishing more clearly between need-to-have capabilities and nice-to-have capabilities.

The need-to-have layer is the one that determines whether the institution can legally operate at scale under modern sanctions expectations. It includes real-time screening of clients and flows, enforcement before signing or release, control over outbound transactions from frozen wallets, support for Travel Rule data and wallet-address intelligence, detection of indirect availability of funds, immediate escalation and reporting, immutable or at least high-integrity auditability, and group-level governance. Those are not differentiators anymore. They are table stakes.

The nice-to-have layer sits above that and helps firms scale with less friction: blockchain analytics deeply integrated into transaction policies, simulation and dry-run environments for rule changes, built-in case-routing and remediation workflows, advanced observability across policy and execution, pre-built integrations to counterparties and sanctions data sources, and configuration models that let compliance teams adapt controls without engineering bottlenecks.

What the French framework really does is force institutions to admit that the “need-to-have” layer belongs inside core wallet and transaction infrastructure, not in a disconnected compliance box.

Start with this “Sanctions Readiness Checklist”

If you cannot answer “yes” to most of these, the gap is likely not compliance. It’s architectural.

1. ‍Real-time control vs. periodic screening
   
   1. Do we enforce sanctions in real time, not just at onboarding or via periodic batch screening?
   2. Can we block a transaction before execution, rather than flag it afterward?
   3. Do we account for indirect exposure (beneficial owners, proxies, delegated access), not just name matching?
   4. If a sanctioned entity interacts with our system today, can we prove we would block them deterministically?‍
2. Execution & latency (critical control point)
   
   1. What is the exact latency between detection and enforcement in our system?
      
   2. Can any transaction be signed or broadcast before sanctions checks complete?
   3. Are there asynchronous steps where a prohibited transfer could slip through?
   4. Are our alert handling and escalation processes compatible with immediate action (seconds/minutes, not hours/days)?‍
3. Coverage & data completeness
   
   1. Do we screen only customers, or also counterparties, transactions, and metadata?
   2. Can we detect when funds are made available indirectly (intermediaries, related parties, routing patterns)?
   3. Do we integrate Travel Rule data, wallet addresses, and blockchain intelligence where relevant?
   4. Can our system adapt dynamically when new information (lists, identifiers, patterns) becomes available?‍
4. Governance & ownership
   
   1. Is there a single accountable owner for sanctions enforcement end-to-end?
   2. Or is responsibility fragmented across compliance, engineering, and product?
   3. Can we demonstrate control at every step (detection → decision → enforcement → reporting)?
   4. Are sanctions controls applied consistently across all entities, subsidiaries, and jurisdictions?‍
5. Architecture & system design
   
   1. Where exactly does enforcement happen in our stack: before signing, at signing, or after execution?
   2. Is policy evaluation enforced pre-execution, or is it a downstream check?
   3. How many systems sit between detection and execution, and do they introduce latency or gaps?
   4. Can we guarantee consistent enforcement across all chains, assets, and transaction types?
   5. Are we operating a coherent control system, or assembling disconnected components (vendors, rules engines, workflows)?

How Dfns maps to the new regulatory compliance needs

The most important regulatory question is no longer whether a wallet platform is secure in the narrow cryptographic sense. It is whether that platform can serve as a real-time control layer inside the transaction path. On that point, Dfns maps well to the emerging expectations described by the French guidelines. Dfns’ policy engine is not described as a reporting or monitoring layer that sits after execution. It is described as a gate that enforces rules before the activity is executed. If a policy is triggered, the activity can either be blocked outright or routed into an approval workflow before it is finalized. Policy evaluation occurs before the MPC ceremony begins: the request is authenticated, checked against permissions, policies, (sometimes validations) then and only then does Dfns proceed to distributed signature generation and broadcast. That sequencing is exactly what institutions need if they are expected to stop prohibited transactions before they are signed rather than explain them after the fact. 

That distinction matters because many compliance stacks still rely on periodic screening or downstream transaction review. Dfns gives clients a way to move sanctions and KYT controls into the live authorization flow itself. Its available policy rules include native controls such as amount limits, velocity limits, and recipient whitelists, but also built-in pre-screening rules for data providers like Chainalysis, Global Ledger, Scorechain, or Notabene. TransactionPrescreening is evaluated on Wallet and Signature activities and that they screen outbound transfers before the transaction is onchain. Likewise, TravelRule is designed to call Notabene before the transfer is executed and wait for a response in the request path. In other words, Dfns is not limited to onboarding-time controls. It supports transaction-level controls that can operate synchronously at the point where value is about to move.

For sanctions enforcement specifically, the difference between flagging and blocking is decisive. Dfns supports both, but the stronger compliance posture is clearly available. A triggered policy can take a Block action, which rejects the activity, or a RequestApproval action, which pauses execution until the required approvers sign off. The approval model supports multiple approval groups and quorums, so a firm can require, for example, one compliance approver and two finance approvers, and the transaction will not proceed unless all required groups reach quorum. Dfns can also prevent the initiator from self-approving by default. This is useful not only for general treasury governance, but also for sanctions-adjacent workflows where the institution wants a deterministic stop by default and escalation only for controlled exception handling.

Another key requirement under the new regulatory model is fail-closed behavior. It is not enough for a provider to say it integrates a screening vendor. Institutions need to know what happens when that vendor times out, the network is unsupported, the asset is unsupported, or the transfer cannot be screened properly. Our prescreening rules document this explicitly through fallbackBehaviours. For instance, the Chainalysis configuration can be set so that unsupported networks, unsupported assets, unscreenable transactions, or Chainalysis failures do not get skipped. The same logic exists for all the other providers. In practice, that means a client can configure Dfns in a strict fail-closed posture: if screening cannot complete, the policy still triggers and the transfer can be blocked. That is highly relevant for sanctions compliance, because it reduces the risk that a prohibited transaction slips through on the basis of a transient provider failure or an unsupported edge case.

Dfns is also useful when firms need to enforce controls based on more than user identity alone. The policy engine can evaluate wallet-specific scope using wallet IDs or wallet tags, and it includes transaction-level rules such as Whitelist, which triggers when funds are sent to a destination address that is not on an approved list. This rule fails closed by default when the recipient cannot be inferred, which is exactly the sort of defensive behavior regulated firms increasingly need. More broadly, Dfns’ built-in integrations let institutions incorporate blockchain-level and counterparty-level data into policy decisions. Compliance pre-screening can evaluate alerts, exposures, detected addresses, risk-score thresholds, as well as validate and transmit Travel Rule data before signing. This means Dfns can sit at the point where upstream compliance signals are converted into actual execution outcomes.

The question of indirect exposure requires more nuance. Dfns does not present itself as a magical sanctions graph engine that automatically models every proxy, nominee, or beneficial ownership pattern. But it does provide important building blocks for enforcing control over how wallets are used inside an institution. Policies can be scoped to particular wallets or wallet groups. Sensitive activities can be gated not only for Wallets:Sign, but also for permission changes and policy changes. The platform supports least-privilege roles and approval workflows across different approver groups, which allows a firm to separate operational authority from governance authority. In practice, that helps institutions model some of the organizational aspects of indirect exposure: delegated access, shared operational responsibility, and the need to prevent a single team or single user from unilaterally changing access or transaction rules. 

Dfns also helps institutions define clear ownership and approval flows around sensitive actions, which is increasingly important as sanctions controls move closer to live operations. The approval model supports multiple groups with separate quorums, and the transaction remains pending until all required groups approve or any one approver rejects it. That makes it possible to create concrete separation of duties between compliance, operations, treasury, and engineering. A firm could, for example, give operations the ability to initiate transfers, require compliance approval for certain high-risk routes or counterparties, and require a different admin quorum for changes to permissions or policies themselves. In that sense, Dfns does not just secure wallets cryptographically. It gives institutions a structured way to express internal governance in the execution path. 

On traceability, Dfns is also strong. The platform exposes audit logs that return the action performed together with signature information from the authentication credential, and we leverage a WebAuthn signature verifier for validation. Indeed, we emphasize PKI- and WebAuthn-based authentication, hardware-rooted credentials, and SSO/OIDC interoperability with enterprise IAM environments. In practical terms, that makes it easier for institutions to know which user, device, role, or approval group initiated or approved a sensitive operation. For sanctions and asset-freeze workflows, that strengthens evidencing, separation of duties, and control over who can move assets under what conditions. 

Combined with policy-triggered approvals and webhook events, this gives clients a meaningful evidentiary layer around who initiated an action, what control path it entered, and whether it was approved, rejected, or blocked. As regulators increasingly care about exact timing and provable enforcement, this kind of auditability matters. It’s not enough to say that “a transaction was screened.” Institutions need to show when the request was made, what policy was applied, whether it was held, who approved it, and whether the signature process ever started.

Finally, Dfns helps address one of the market’s biggest practical problems: the temptation to assemble sanctions and wallet infrastructure from too many disconnected components. Dfns supports over 100 integrated blockchains and third-party services. The platform is built around a unified model where a single key pair can operate across multiple networks, with consistent support for signing and workflows across diverse blockchain environments. For institutions that need a coherent governance and enforcement posture across chains, this is critical. A sanctions control plane is only as effective as its ability to apply uniformly across the assets and rails a firm actually uses.

Because Dfns combines organization- and user-managed wallets, an in-line policy engine, approval workflows, external prescreening integrations, and auditable execution, it reduces the number of places where a compliance decision can be lost between detection and signing. That does not eliminate the need for upstream screening, sanctions data providers, or legal analysis. But it does give institutions something they increasingly need under modern sanctions expectations: a single execution layer where screening outcomes, governance rules, and transaction authorization can be tied together deterministically. For regulated firms trying to preserve operational speed without creating a fragile patchwork of internal builds and vendor glue, that is probably the most important part of the value proposition. 

Final words

The French Treasury and ACPR guidelines, aligned with the EU’s MiCA regulation coming into force in July 2026, confirm a structural shift that has been underway for some time. Asset-freeze obligations apply directly to financial institutions, including crypto-asset service providers. That means the systems these firms rely on for wallet management, transaction execution, and value transfer are no longer peripheral technical tools. They sit inside the enforcement layer of international sanctions.

This is an obligation of result, not effort. Missing a sanctioned entity or allowing a prohibited transfer to proceed is not a regrettable best-effort miss. It is a control failure with legal consequences. Execution must be immediate. Screening and enforcement cannot be deferred to the back office, and operational latency in the transaction path is becoming harder to defend. 

Coverage must extend across users, flows, counterparties, intermediaries, wallets, and indirect patterns of access to value. In crypto, it must increasingly incorporate Travel Rule data, wallet-address intelligence, and, where appropriate, blockchain analysis.

Compliance therefore has to be embedded by design. The wallet layer is no longer just a signing system. It is becoming, in institutional finance, a programmable compliance and execution layer. And that is the real message of the French Treasury and regulators. It is not simply telling the market to screen better. 

It is telling the market to redesign the place where control actually happens.

Get started on Dfns: app.dfns.io/get-started