Banks have spent decades building compliance programs around payment rails they understand: SWIFT, ACH, card networks, correspondent banking. Each rail has a defined data model, a known counterparty set, and a regulatory framework that examiners have interpreted over many cycles. Digital assets break nearly all of those assumptions.
Blockchain addresses are pseudonymous. Transactions are irreversible. Counterparties may be DeFi protocols with no legal entity behind them. Jurisdictional attribution is uncertain. And transaction volume can be orders of magnitude larger than what a compliance team is sized to review manually.
The banks that are moving carefully are building programs that map on-chain controls to the frameworks they already have: BSA, OFAC, CDD/EDD, and the three-lines-of-defense model. The ones moving fast without that mapping are building a regulatory event.
What traditional AML standards require on-chain
The Bank Secrecy Act, FinCEN guidance on virtual currencies, and the EU's AML directives require the same basic things: know your customer, monitor transactions for suspicious patterns, and report to the appropriate financial intelligence unit. These obligations do not stop when a transaction involves a blockchain.
For a bank that holds digital assets in custody, accepts stablecoin deposits, or provides settlement services, the AML obligations mirror any other payment service. The difference is that the data needed to fulfill those obligations does not arrive in the structured form it does on traditional rails. Who owns a given address, what entity is on the other side, whether a counterparty is sanctioned: none of that is provided by the transaction itself.
CDD and EDD apply to on-chain counterparties the same way they apply to correspondent banks. The bank still needs to establish who it is transacting with. The on-chain attribution layer is the mechanism that makes that possible. Without it, the bank cannot clear the basic Customer Due Diligence rule for a meaningful share of its transactions.
The first line of defense is the business unit executing digital asset transactions. It needs tooling that produces attribution and risk signals at transaction time, not after the fact. The second line is compliance. It needs to validate that those controls work and that the risk assessment is documented. The third line is internal audit. It needs to verify both without relying on the vendor to explain the model. Each line has a different need. The program has to serve all three.
The SAR problem for crypto transactions
Filing a Suspicious Activity Report for a cryptocurrency transaction is harder than filing one for a wire transfer. The narrative must explain the suspicious activity in enough detail that the receiving FIU can act on it. It must cite evidence a reviewer can independently verify.
For a wire transfer, the narrative references account numbers, amounts, and the specific pattern that triggered the flag. For a blockchain transaction, the narrative must explain the address attribution (why this address connects to a sanctioned entity), the transaction graph showing how funds flowed, and the confidence level of the attribution. Most bank compliance analysts have not been trained in blockchain tracing. They cannot produce that narrative from scratch in a reasonable timeframe.
Banks that have solved this have done it two ways: tooling that produces the investigation graph and attribution automatically, and output written in plain language that analysts can review, edit, and file. Strix generates the on-chain SAR narrative in seconds, with full attribution provenance the receiving FIU can verify. The analyst's role shifts from doing the tracing to reviewing and approving the output.
The quality of that output is not a UI question. It is a model risk question. The analyst approving the narrative needs to know how the attribution model reached its conclusions, what the confidence intervals are, and what the false positive rate looks like at scale. If the analyst cannot explain those things to an examiner, the SAR is not defensible.
Model risk and SR 11-7
Any bank deploying an AI or algorithmic model for AML, sanctions screening, or fraud detection must manage it under the Federal Reserve's SR 11-7 guidance, or its OCC and FDIC equivalents. SR 11-7 requires model development documentation, independent validation, and ongoing monitoring for performance drift.
This is not optional. A blockchain attribution tool that generates risk scores and SAR narratives is a model under SR 11-7. The bank's Model Risk Management team will ask for it to be inventoried, validated, and periodically reviewed. Vendors who have not prepared for this conversation will not clear the model risk review.
The questions MRM will ask are specific. What training data was used? How was the labeling methodology validated? What is the expected false positive rate for sanctioned-entity attribution? How is model drift detected when the on-chain environment changes, for example when a sanctioned entity migrates to a new address cluster? Is there a challenge process for the model's outputs?
Banks should require vendors to provide model documentation that answers these questions before procurement, not after. A vendor that cannot produce that documentation is not ready for a regulated banking environment. Building the model risk case after signing the contract is expensive and slow.
Data sovereignty and deployment topology
Bank compliance programs have requirements that fintech programs typically do not. Data sovereignty rules govern where customer transaction data can be processed and stored. Sending that data to a multi-tenant SaaS API may violate those rules depending on jurisdiction and data classification.
This shapes which blockchain analytics tools a bank can actually use. The SaaS model (submit an address, receive a risk score) fails the data sovereignty test in most Tier 1 and Tier 2 bank environments. A tool that is technically capable but architecturally incompatible will not survive the third-party risk review.
The deployment topologies banks actually accept fall into a short list. On-premises deployment inside the bank's own data center. Private cloud deployment inside the bank's VPC, with no data egress to the vendor. Air-gapped deployment for the highest-sensitivity environments. Sovereign cloud deployment in a jurisdiction-specific cloud region, with contractual guarantees that data stays within the jurisdiction.
SR³ supports all of these topologies. The scoring engine, the label database, and the investigation tooling run inside the bank's perimeter. No customer transaction data leaves the network. The compliance output is generated locally and stays within the bank's systems: risk scores, investigation graphs, SAR narratives.
Integration with existing case management systems matters too. The bank likely runs a case management platform. Cases need to flow from the analytics tooling into that system, not create a parallel workflow. A tool that generates good outputs but requires analysts to copy-paste between systems will fail adoption.
Vendor qualification and third-party risk
Banks run structured third-party risk management programs. A blockchain analytics vendor seeking approval in a Tier 1 bank environment should expect to answer a questionnaire covering information security, operational resilience, data handling, and subprocessor relationships. Most vendors have not been through this process.
The minimum threshold for most banks includes SOC 2 Type II attestation, evidence of annual penetration testing, a documented incident response plan, and a data processing agreement that covers the bank's regulatory obligations. ISO 27001 certification is increasingly expected. Subprocessors need to be disclosed and evaluated on the same criteria.
Model risk management approval is separate from information security approval. Both have to clear before the tool goes into production.
Procurement timelines at banks are long. A vendor who shows up without these documents at the start of the conversation will extend that timeline by months. The bank's third-party risk team will not waive the questionnaire, and the compliance team cannot proceed without third-party risk clearance.
Banks evaluating vendors should ask early: what is your SOC 2 status, when does it renew, and what is your process for sharing your penetration testing results under NDA? Vendors who hesitate on these questions are not ready.
What examiners look for
When an OCC or Fed examiner reviews a digital asset compliance program, they ask the same questions they ask about any AML program: is the risk assessment reasonable and documented? Are SARs filed on time with sufficient detail? Is the compliance function resourced relative to the risk? Are policies documented and actually followed?
The specific questions for digital assets cluster around four areas. How does the bank identify the real-world entity behind an address? How does the bank monitor transactions for patterns suspicious in traditional banking: structuring, rapid layering, movement to mixing services? What does the bank do when a sanctioned address is identified? How long does it take the compliance team to produce a complete investigation package on demand?
The examiner will also ask about model risk. Is the attribution tool in the model inventory? Has it been independently validated? Who is the model owner? How is performance monitored?
Banks that perform well on these dimensions have invested in attribution infrastructure before the examiner visits. The examination is a lagging indicator. A program built in response to findings is a program built under consent order pressure. The banks that are ahead of this have made on-chain compliance a permanent part of their first and second lines of defense. It is not a project, and it is not a vendor's problem to solve after the fact.
The board conversation is the forcing function. When the digital assets initiative comes to the board for approval, the CRO needs to present a risk framework that is coherent, documented, and connected to the bank's existing risk appetite. "We are using a reputable blockchain analytics vendor" is not a framework. A documented control environment is: model risk approval, data sovereignty architecture, and an examiner-ready investigation workflow.
Banks that treat digital asset compliance as a strategic capability build it that way from the start. The ones that treat it as a checkbox will find the check does not hold under examination.