Stablecoin Compliance: Broker-Dealer
The three-control-point AML framework for broker-dealer stablecoin operations — pre-broadcast screening, attributed value transfer via IVMS101, and post-settlement change-of-risk monitoring — built on the principle of attributed transparency.
Definition
Stablecoin AML compliance for broker-dealers rests on a single foundational distinction: a stablecoin transfer is a transparent event on a public ledger and a silent event in the identity system. The ledger records every fact about the transfer — amount, addresses, timestamp, prior transaction history of both parties — with a precision and permanence that no traditional wire system can match. The identity system records nothing unless the firm builds and maintains the layer that connects wallet addresses to verified legal entities. The interaction between these two characteristics determines whether a broker-dealer's stablecoin AML program is genuinely more capable than its cash equivalent, or whether it is merely operating a transparent rails system without the identity layer that makes transparency useful.
This article is a first-principles guide to stablecoin AML for broker-dealers. It focuses on the structural control points, the technical standards, and the risk frameworks that underpin any compliant stablecoin AML program regardless of which specific rules or thresholds are current. Threshold amounts, specific rule citations, and jurisdictional definitions change; the principles of lifecycle control, attributed transfer, and deterministic identity do not. For the foundational BSA/FINRA compliance program that this article builds on, see AML Transaction Monitoring.
The Core Principle: Attributed Transparency
Traditional money laundering exploits the opacity of cash and the fragmentation of financial records across institutions. An AML analyst reconstructing a cash transaction chain must request records from each institution in the payment path, wait for responses, and assemble a picture that is inherently incomplete — each institution holds only its segment. The analyst makes a probabilistic risk judgment based on available signals.
Stablecoin AML operates on different ground. A public blockchain maintains a complete, immutable record of every transaction for every address since the network's inception. There is no segment held by a single institution. There is no request-and-wait cycle. The entire on-chain history of every address involved in a stablecoin transfer is publicly accessible in seconds. This is attributed transparency: the capacity to construct a deterministic, complete transaction graph for any counterparty wallet at any point in time, using public ledger data enriched with blockchain analytics attribution.
The word "deterministic" is precise. In probabilistic AML, the analyst infers risk from incomplete data. In deterministic AML, the analyst verifies fact from complete data. If the identity layer is solid — if the firm knows that Wallet A belongs to Entity X with a verified, documented link — then the AML determination is not a probability judgment; it is a verification against an immutable record. This structural shift is not inherent to all stablecoin transactions; it is the result that follows when the broker-dealer builds and maintains the identity layer correctly. Without that layer, the transparent ledger is useful intelligence but not a compliance foundation.
The Three Control Points: Lifecycle AML
Lifecycle AML organises stablecoin AML controls around three sequential control points, rather than applying a single monitoring layer to a batch of completed transactions. Each control point is distinct in timing, mechanism, and the category of risk it addresses.
Control Point 1: Pre-Broadcast Screening
The first and most consequential control point is pre-broadcast screening: checking the destination wallet address before the transaction is submitted to the network. Once a stablecoin transaction is broadcast and confirmed, it is immutable. There is no settlement reversal instruction, no recall mechanism equivalent to a SWIFT gpi recall, and no RTGS cancellation window. The pre-broadcast moment is the only point at which the firm has unilateral, costless ability to prevent a violative transfer. After broadcast, options are limited to contacting the stablecoin issuer for an emergency freeze (available only for certain regulated stablecoins that maintain contract-level freeze capability, and not guaranteed) or accepting the completed transfer and managing the AML consequence.
Pre-broadcast screening has two distinct components. Sanctions screening verifies that the destination address does not appear on applicable sanctions lists — OFAC's Specially Designated Nationals list, UN consolidated sanctions lists, and any relevant domestic or counterparty-jurisdiction sanctions regimes. Several regulated stablecoins maintain issuer-level address blacklists and can freeze token balances at sanctioned addresses; this is a secondary control, not a substitute for the firm's own pre-broadcast check. Blockchain analytics risk scoring assesses the destination wallet's on-chain history for associations with high-risk entities: darknet markets, sanctioned exchange accounts, mixing services, high-risk jurisdictional on-ramps, or wallets previously identified in AML investigations. The risk score represents the wallet's known history at the moment of the check; it is not a guarantee about future behavior.
The workflow implication: pre-broadcast screening must be embedded in the trade enrichment chain, not executed as a post-trade compliance review. The check must complete before the settlement instruction is transmitted to the signing and broadcast layer. A broker-dealer that screens wallet addresses the day after settlement is not performing pre-broadcast screening — it is performing post-trade review of already-immutable transactions, which provides evidence but not control.
Control Point 2: Attributed Transfer
The second control point addresses the identity gap in on-chain transfers. A stablecoin transfer between two wallet addresses is a silent event from an identity perspective. The ledger records: a transfer of X tokens from Address A to Address B at time T. It does not record: who controls Address A, who controls Address B, or for what business purpose the transfer was made. Without a parallel identity layer, the on-chain settlement record satisfies the transparency requirement — every fact about the transfer is visible — but does not satisfy the attribution requirement that regulated institutions impose on counterparty transfers.
The Travel Rule principle — that originator and beneficiary identity information must travel with a regulated value transfer — is the obligation that attributed transfer fulfills. In traditional wire settlement, this is structural: SWIFT messaging fields carry originator and beneficiary data as part of the payment instruction itself. In stablecoin settlement, it is not structural; it requires a deliberate, parallel messaging step. The information that must travel with the value does not travel automatically.
IVMS101 (Inter-VASP Messaging Standard 101) is the data schema that defines what information must be exchanged between regulated institutions to satisfy the attributed transfer requirement. It specifies the required data elements — originator legal name or entity name, originator account identifier (the wallet address), originator geographic address or LEI, and the equivalent beneficiary fields — and their encoding format. IVMS101 is the common language of Travel Rule compliance infrastructure: the major interoperability platforms all use it as their underlying schema. Its value is not jurisdiction-specific — the schema works for U.S. Funds Transfer Recordkeeping compliance, FATF Recommendation 16 compliance, EU Transfer of Funds Regulation compliance, and equivalent frameworks in other jurisdictions because it defines the information requirement, not the regulatory threshold.
A broker-dealer without connectivity to a Travel Rule messaging platform cannot fulfill the attributed transfer requirement for institutional stablecoin transactions. The practical test: for every stablecoin transfer above the applicable Travel Rule threshold, can the firm confirm that IVMS101 originator and beneficiary data was transmitted to the counterparty institution and received in turn? If not, the transfer was a silent event in the identity system regardless of how visible it is on the ledger.
Lifecycle AML — three control points for stablecoin settlement
| Control Point | Timing | Mechanism | Risk Addressed | Key Limitation |
|---|---|---|---|---|
| Pre-broadcast screening | Before mempool submission | OFAC SDN + blockchain analytics | Sanctions exposure, high-risk routing | Point-in-time — wallet risk evolves post-check |
| Attributed transfer | Concurrent with settlement | IVMS101 messaging, VASP directory | Identity gap in on-chain value transfer | Requires counterparty Travel Rule connectivity |
| Post-settlement monitoring | Ongoing | Cluster analysis, graph traversal, alerts | Change of risk, peeling chain detection | Retroactive — cannot reverse settled transactions |
| Deterministic identity mapping | Pre-onboarding + ongoing | LEI-to-wallet registry, key verification | Pseudonymous transfer, false attribution | Active maintenance — wallet rotation creates gaps |
Control Point 3: Post-Settlement Change-of-Risk Monitoring
The third control point addresses the temporal limitation of pre-broadcast screening: a risk assessment conducted at trade date reflects the counterparty wallet's history and known affiliations as of that moment. The wallet's risk profile continues to evolve after settlement. Post-settlement change-of-risk monitoring is the ongoing surveillance of counterparty wallet addresses to detect material developments that would alter the firm's risk assessment of the relationship.
A change-of-risk event is any on-chain development materially inconsistent with the risk profile established at onboarding and trade date. The operationally significant categories are: interaction with a known mixing or obfuscation service (indicating an intent to break the transaction graph and obscure the origin of funds); receipt of funds from a sanctions-listed address (tainting the wallet's balance with funds of identifiable illicit origin); appearance in a blockchain analytics cluster newly attributed to a darknet market, fraudulent exchange, or other high-risk entity; and velocity anomalies — large amounts transiting the wallet in short periods inconsistent with the counterparty's stated business profile. A wallet that was clean at trade date can exhibit all four characteristics within weeks of settlement.
Post-settlement monitoring does not reverse the settled transaction — finality is finality — but it serves two forward-looking functions. First, it determines whether a SAR review is required: a change-of-risk event that raises the question of whether the original settlement was part of a layering pattern not detectable at trade date triggers the initial detection clock for SAR purposes. The 30-day window begins when the firm becomes aware of facts suggesting suspicious activity. Second, it informs ongoing counterparty relationship management: a counterparty whose wallet exhibits post-settlement change-of-risk events is a counterparty whose AML risk profile must be reassessed before further transactions are authorized.
The Identity Bridge: Linking Wallet Addresses to Legal Entities
The identity layer is what makes attributed transparency operationally realizable rather than aspirational. Its construction and maintenance are the most demanding operational requirements in a stablecoin AML program.
A wallet address is a pseudonym, not an identity. It is a string derived from a public key — it identifies a cryptographic account, not a legal person or entity. Wallet addresses can be generated in seconds and discarded; a single entity can control thousands; addresses are reused across transactions or rotated after each transfer, depending on operational practice. None of this is visible in the on-chain record.
Deterministic identity mapping is the process of establishing a verified, documented link between a wallet address and a GLEIF-issued Legal Entity Identifier or equivalent verified identity credential. Deterministic means not inferred from statistical co-spending patterns or transaction graph analysis — it means established through a direct verification step: the legal entity demonstrates control of the wallet address through a cryptographic signature or direct address disclosure in the onboarding process, and the mapping is recorded in the firm's counterparty registry with the verification method documented.
VASP counterparty due diligence requires this mapping for every institutional counterparty wallet. Before transacting with any wallet in a material stablecoin flow, the broker-dealer must have: a documented LEI-to-wallet link; a record of the verification method; a KYC refresh schedule; and a process for updating the mapping when the counterparty rotates wallet addresses. Wallet rotation — a common operational practice in institutional digital asset management, often triggered by custodian infrastructure upgrades — is the most frequent source of identity mapping gaps. A counterparty that rotates its wallet address without notifying the broker-dealer creates an unattributed address in the firm's next settlement instruction. Procedures for wallet address change notification and re-verification must be part of the VASP counterparty due diligence program.
Programmable Compliance: The Structural Advantage
The attributed transparency of stablecoin AML is not only operationally advantageous for individual firms; it represents a structural shift in how financial surveillance operates. Traditional AML relies on institutional intermediaries as the source of evidence: each bank sees its segment, reports what it sees, and the financial intelligence unit assembles the picture from filings. The evidence base is fragmentary, delayed, and dependent on the cooperation of multiple institutions across jurisdictions.
In a stablecoin ecosystem where the ledger is public and blockchain analytics can attribute addresses to known entities, the evidence base is complete, immediate, and accessible without institutional cooperation. A regulatory authority investigating a suspicious stablecoin flow does not need to issue subpoenas to five correspondent banks in three jurisdictions; it can read the on-chain record directly and enrich it with analytics attribution. This is programmable compliance: the compliance audit trail is embedded in the ledger itself, available to any authorized reviewer at any time.
For broker-dealers, programmable compliance has a practical implication for how AML programs are structured and examined. An AML program for stablecoin operations that is well-built — with deterministic identity mapping, pre-broadcast screening, attributed transfer, and post-settlement monitoring — produces a richer and more verifiable audit trail than any traditional AML program for cash settlement. The examiner can verify: what wallet addresses did the firm transact with; were those addresses screened before broadcast; was IVMS101 data transmitted and received; were change-of-risk events detected and acted upon. Each of these facts is verifiable against immutable records. A firm with complete lifecycle AML controls on its stablecoin operations is in a structurally stronger examination position than a firm relying on probabilistic cash AML — and a firm with missing controls is in a structurally exposed position because the gaps are equally visible on the same ledger.
VASP Counterparty Classification
A broker-dealer transacting in stablecoins must determine whether its counterparties qualify as Virtual Asset Service Providers under applicable regulatory definitions, and conduct VASP-specific due diligence accordingly. VASP classification is not a static determination: the definition varies by jurisdiction and has evolved as regulatory frameworks have developed. The operational principle that is stable across frameworks is the FATF Recommendation 15 standard: an entity that facilitates the transfer, exchange, or custody of virtual assets on behalf of clients is functionally a financial intermediary subject to AML obligations, regardless of its precise legal label in any one jurisdiction.
VASP counterparty due diligence requires verification of: the counterparty's regulatory authorization or licensing in its home jurisdiction; its AML program status (does it maintain a written AML program that meets the standards of its jurisdiction?); its Travel Rule compliance capability (is it connected to a Travel Rule messaging platform and able to send and receive IVMS101 data?); and the current status of its deterministic identity mapping for the wallet addresses it uses in institutional transactions. A counterparty that cannot confirm Travel Rule connectivity and cannot provide verified wallet address ownership documentation is a counterparty with whom attributed transfer is not possible — settlement with that entity creates a structural AML gap that pre-broadcast screening and post-settlement monitoring cannot fully compensate for.
Lifecycle AML — stablecoin settlement control points
Devancore Glossary · devancore.com
Lifecycle AML — stablecoin settlement control points
Devancore Glossary · devancore.com
How it works
1. Counterparty Onboarding and Deterministic Identity Mapping
AML-compliant stablecoin settlement begins before any transaction is initiated. Every institutional counterparty must be onboarded with deterministic identity mapping: the counterparty provides the wallet addresses it will use for stablecoin settlement, and the broker-dealer verifies that those addresses are controlled by the counterparty entity through a documented verification process — typically a cryptographic signature (the counterparty signs a message with the private key corresponding to the wallet address, proving control without disclosing the key) or direct disclosure in the onboarding documentation. The verified mapping is recorded in the firm's counterparty registry alongside the counterparty's GLEIF-issued LEI, KYC documentation, and VASP classification determination. The registry must include a refresh trigger: KYC recertification, wallet address rotation, or change in the counterparty's regulatory status are all events that require the mapping to be re-verified. A counterparty whose wallet address cannot be deterministically mapped to a verified legal entity cannot be approved for institutional stablecoin settlement; transacting with an unattributed address is an AML control failure regardless of whether the transaction is otherwise legitimate.
2. VASP Due Diligence and Travel Rule Readiness Assessment
For counterparties classified as VASPs — entities that facilitate virtual asset transfers, exchanges, or custody on behalf of clients — an additional due diligence layer applies. The broker-dealer must verify the counterparty VASP's AML program status (does it maintain a written AML compliance program that meets the standards of its licensing jurisdiction?), its regulatory authorization or licensing, and its Travel Rule compliance capability. Travel Rule readiness means the counterparty is connected to a Travel Rule messaging platform — TRUST, Veriscope, TRISA, or an equivalent IVMS101-compatible system — and able to send and receive required originator and beneficiary data for transactions above the applicable threshold. A VASP that is not Travel Rule-connected cannot participate in attributed transfer; the broker-dealer's settlement with that counterparty will be a silent event in the identity system regardless of how thoroughly the broker-dealer has built its own messaging infrastructure. VASP due diligence documentation — licensing verification, AML program attestation, Travel Rule connectivity confirmation — is maintained in the counterparty registry alongside the deterministic identity mapping and KYC file.
3. Pre-Broadcast Screening: OFAC and Blockchain Analytics
When a settlement instruction is generated — whether from a trade execution, a collateral posting, or a fund subscription — the destination wallet address is routed to the pre-broadcast screening step before any signing or broadcast action occurs. Sanctions screening checks the address against OFAC's SDN list, the UN consolidated sanctions list, and any additional jurisdiction-specific lists applicable to the transaction. A confirmed OFAC match is an automatic block: the transaction is halted, the alert is escalated to the AML compliance officer, and no settlement is authorized until the match is resolved. Blockchain analytics scoring evaluates the destination address's on-chain history against the analytics provider's entity attribution database: is this address associated with known high-risk entities — darknet markets, fraud operations, mixing services, or sanctioned exchanges? The risk score is returned as a numerical value and a risk category. Addresses scoring above the firm's defined elevated threshold are flagged for manual AML review; addresses scoring below proceed to the attributed transfer step. Pre-broadcast screening results are recorded in the trade record, creating an auditable documentation of the control being exercised. The screening step must execute within the trade lifecycle, not as a separate post-trade review. A gap between settlement broadcast and screening execution is a control failure.
4. IVMS101 Data Assembly and Travel Rule Messaging
For transactions above the applicable Travel Rule threshold, the originator data assembly step runs concurrently with pre-broadcast screening preparation. The firm's Trade Enrichment layer retrieves the originator's required IVMS101 data elements from the counterparty registry: the originator's legal entity name, LEI, geographic address, and the originating wallet address. The beneficiary data elements are retrieved for the receiving counterparty. This assembled payload is the IVMS101 message that will be transmitted to the counterparty institution before or concurrent with settlement. The IVMS101 message is sent through the firm's Travel Rule messaging platform to the counterparty's messaging endpoint. The counterparty transmits the equivalent beneficiary-side data in return. Both the outbound and inbound IVMS101 messages are retained in the trade record alongside the on-chain transaction reference — they are the attributed transfer documentation that demonstrates the requirement was met. If the counterparty is not Travel Rule-connected and cannot receive the IVMS101 message, the transaction cannot proceed as an attributed transfer; the compliance team must determine whether the transaction should be blocked or processed with documented exception handling.
5. Settlement Authorization and Broadcast
Settlement authorization is the step at which the pre-broadcast screening result and Travel Rule messaging completion are confirmed before the transaction is submitted to the network. The authorization checkpoint verifies: OFAC screening passed; blockchain analytics risk score below the elevated threshold (or manual review cleared); IVMS101 message transmitted and counterparty acknowledgement received (or exception documented). When all conditions are met, the settlement instruction is authorized, signed with the operational wallet's private key, and broadcast to the network. The broadcast timestamp and transaction hash are recorded immediately as part of the trade record. The settlement is irrevocable from this point. Any post-broadcast AML concern is addressed through post-settlement monitoring and the SAR workflow — there is no broadcast reversal mechanism.
6. Finality Confirmation and Trade Record Update
Settlement finality is confirmed when the transaction reaches the required block confirmation depth for the network — the threshold at which the transaction is considered irreversible under the network's consensus rules. Devancore tracks confirmation depth against the configured finality threshold and updates the trade record upon confirmation. The trade record includes: the transaction hash, block number, confirmation timestamp, confirmation depth, originating and destination wallet addresses, IVMS101 message references for both the outbound and inbound Travel Rule transmissions, pre-broadcast screening result and timestamp, and blockchain analytics risk score at the time of screening. This is the Rule 17a-3-compliant trade record for a stablecoin settlement — it documents not only that the settlement occurred but that the lifecycle AML controls were applied.
7. Post-Settlement Change-of-Risk Monitoring
After settlement is confirmed, every counterparty wallet address in the transaction is added to or confirmed in the firm's ongoing change-of-risk monitoring registry. The monitoring function runs continuously against the blockchain analytics provider's attribution update feed: when any registered address interacts with a newly attributed high-risk entity, receives funds from a sanctions-listed address, appears in a newly identified illicit cluster, or exhibits velocity anomalies, an alert is generated. The alert triggers a review workflow: AML compliance reviews the original transaction, assesses whether the change-of-risk event retrospectively elevates the risk of the original settlement, determines whether a continuing relationship with the counterparty is appropriate, and decides whether a SAR should be filed. The decision and supporting rationale are documented regardless of outcome — the documentation demonstrates that the firm detected the change-of-risk event, acted promptly, and exercised judgment in accordance with its written AML procedures. Change-of-risk alerts that are cleared without SAR filing are closed with a documented rationale; those that result in SAR filings follow the standard SAR workflow, with the initial detection date recorded as the date the change-of-risk alert was generated.
8. SAR Workflow for Stablecoin Suspicious Activity
The SAR workflow for stablecoin transactions follows the same 30-day filing obligation as traditional cash SAR filings, with additional documentation requirements specific to on-chain activity. The SAR narrative for a stablecoin transaction must include the on-chain transaction hash and address information alongside the standard counterparty and transaction description. Blockchain analytics outputs — entity attribution, risk scoring rationale, cluster membership — are attached as supporting documentation: they form the evidentiary basis for the suspicion, and because they reference immutable on-chain records, they are verifiable by FinCEN or law enforcement independently of the SAR filer's records. Continuing activity SARs are filed on the 90-day cycle for persistent suspicious patterns; for stablecoin transactions involving a counterparty wallet exhibiting ongoing change-of-risk developments, the monitoring registry ensures that the 90-day window is tracked and not missed. The SAR documentation for a well-run stablecoin AML program is structurally more detailed than the equivalent cash SAR, because the on-chain record provides a complete, immutable transaction graph that can be attached directly.
Pre-broadcast screening — decision flow
Devancore Glossary · devancore.com
Pre-broadcast screening — decision flow
Devancore Glossary · devancore.com
In Devancore™
Devancore — stablecoin AML control chain
Devancore Glossary · devancore.com
Devancore — stablecoin AML control chain
Devancore Glossary · devancore.com
Devancore's stablecoin AML module is built on the first principle of attributed transparency: every USDC settlement the platform processes generates a full lifecycle AML record — pre-broadcast screening result, IVMS101 attribution data, settlement confirmation, and post-settlement monitoring status — as a single audit trail alongside the trade record. The module is not a separate compliance system that receives data from the settlement layer; it is the settlement layer, with AML controls embedded at each control point in the workflow rather than applied after the fact.
Pre-Trade Gating
Before any USDC settlement instruction is authorized for signing and broadcast, Devancore automatically submits the destination wallet address to the configured pre-broadcast screening stack: OFAC SDN check, relevant international sanctions lists, and the connected blockchain analytics provider's risk scoring API. The result is returned within the trade enrichment workflow — an OFAC hit halts the instruction immediately and surfaces an AML exception for compliance review; an elevated risk score routes the instruction to a manual review queue; a clean result and acceptable risk score clear the instruction for the IVMS101 attribution step. The screening result, timestamp, and risk score are written to the trade record at this point, creating the pre-broadcast documentation regardless of the outcome. Devancore's pre-trade gating prevents violative transactions at the protocol layer — the settlement instruction is not transmitted to the signing service until the gating check has completed. There is no mechanism by which a trade can reach broadcast without a pre-broadcast screening result in the record.
Identity-on-Rail: IVMS101 Messaging Bridge
Devancore provides the messaging bridge needed to attach originator and beneficiary data to stablecoin transfers, ensuring compliance with the Travel Rule principle regardless of jurisdiction. When a settlement instruction clears pre-trade gating, the platform retrieves the IVMS101 payload from the counterparty registry — originator name, LEI, geographic address, and originating wallet address; beneficiary name, LEI, and destination wallet address — and transmits it to the counterparty institution through the configured Travel Rule messaging platform. The transmission timestamp and counterparty acknowledgement are written to the trade record. For counterparties whose Travel Rule connectivity is not yet established, Devancore surfaces a connectivity gap alert at the trade enrichment stage, before the instruction reaches the gating check — giving compliance teams advance warning rather than a blocked settlement at the authorization step. The IVMS101 records retained in Devancore's trade record system serve as the attributed transfer documentation for examination: they demonstrate that for every settlement above threshold, identity information traveled with the value.
Cluster Analysis Integration and Change-of-Risk Monitoring
After each stablecoin settlement is confirmed, Devancore registers the counterparty wallet addresses in its post-settlement monitoring layer. The platform maintains a continuous feed from the connected blockchain analytics provider, alerting the AML compliance team when any registered address triggers a change-of-risk event: interaction with a mixer, receipt from a sanctions-listed address, cluster reassignment to a high-risk entity, or velocity anomaly inconsistent with the counterparty's documented business profile. Alerts are surfaced in the operations dashboard with the original transaction reference, the change-of-risk event description, and the current risk score, alongside the risk score at the time of the original pre-broadcast check. This delta view — what the wallet scored at trade date vs what it scores today — is the key input for the AML compliance officer's SAR determination: a wallet that scored 12 at trade date and now scores 78 following mixer interactions is a different risk conversation from a wallet that scored 60 at trade date and has remained stable. Devancore correlates internal trade records with the external blockchain analytics event to produce the change-of-risk AML alert, combining the firm's own LEI-to-wallet mapping with on-chain provenance analysis to provide a single, documented risk event for compliance review.
Deterministic Identity Registry
Devancore maintains the firm's LEI-to-wallet mapping registry as a live operational data store, not a static onboarding record. The registry tracks: the wallet address, the verified LEI of the controlling entity, the verification method and date, the KYC re-certification due date, and the date of any last wallet rotation notification received from the counterparty. Wallets approaching KYC recertification due dates are flagged 30 days in advance — the same lead time as the TMMF whitelist manager — ensuring that the identity mapping does not lapse before the recertification completes. When a counterparty notifies Devancore of a wallet address rotation, the platform creates a new mapping record for the new address and places the old address in a deprecated state, tracking the transition window until the new address's deterministic mapping is verified and confirmed. During the transition window, settlement instructions to the old address are flagged for manual review; instructions to the new address are held until the verification is complete. This prevents the most common source of identity mapping gaps — unannounced wallet rotation — from creating unattributed transfer risk in the middle of an active counterparty relationship.