Six Layers of Proactive Compliance in Crypto Products: Trustee Plus Case

The regulatory question for crypto companies is no longer “Do you have an AML policy?” That bar was cleared years ago. Today’s regulators, banking partners, and supervisory bodies ask something harder: “Can you prove your controls actually work?”

Across jurisdictions, VASP requirements are tightening. Travel Rule enforcement is expanding. AML/CFT standards are being updated. Sanctions screening scope is widening. And banking partners increasingly ask not for policy declarations, but for reproducible operational procedures with documented risk thresholds and auditable outcomes.

For crypto wallets, exchange services, and crypto neobanks, this means a shift from declarative compliance to operational compliance. Decisions must be documented, risk thresholds configured, and system responses reproducible and verifiable.

This shift is especially significant for products that sit at the intersection of a crypto wallet, a payment card, and financial infrastructure. Historically, many such services operated reactively: a user receives a deposit, funds land on their balance, and the problem surfaces later — at withdrawal, during an exchange, on a card transaction, or in a review by a banking partner. If the asset’s transaction history traces back to a sanctioned service, a mixer, a darknet market, or stolen funds, the user faces a hold, source-of-funds requests, and sometimes weeks of back-and-forth with support.

For the user, this looks like a sudden freeze. For the company, it’s an expensive investigation, a reputational risk, and a potentially negative supervisory record. That’s why a different model is emerging: AML screening of incoming transactions before funds are credited to the user’s balance. 

Why Reactive AML No Longer Works

Blockchain has no built-in marker that makes a coin “Clean” or “Dirty.” Tokens of the same standard are technically fungible, and the network doesn’t perform sanctions screening on its own. The exception is centralized stablecoins, where the issuer can freeze addresses at the smart contract level. In all other cases, AML control doesn’t exist in the blockchain — it exists at the intermediary layer: wallets, exchanges, payment providers, card issuers, on/off-ramp services, and analytics providers.

This creates an important asymmetry. The network can confirm a transaction, but a regulated service is still required to assess its origin. If the sender’s address is linked to a sanctioned cluster, a mixer, stolen funds, or a ransomware group, the risk transfers to the recipient and the platform accepting the deposit.

For retail users, this can happen not only through deliberate interaction with criminal infrastructure. A bad P2P trade, a transfer from a counterparty with an opaque history, or a deposit from a service that itself turned out to be linked to high-risk flows — these are all enough. The user sees an ordinary transfer. The compliance system sees a chain of fund movement.

For a product operating in the neobanking model, the reactive approach creates three problems:

• Loss of Trust. A user whose funds enter an undefined AML hold rarely experiences it as a normal regulatory procedure. To them, it’s a broken product.
• Operational Load. Every post-credit incident requires case management: transaction analysis, user communication, document requests, source-of-funds assessment, and sometimes coordination with external partners.
• Regulatory Exposure. Having an AML Policy is no longer sufficient evidence of control. Supervisors and banking partners expect companies to prevent risk, not just investigate it after the fact.

Pre-Deposit Screening as an Architectural Decision

Pre-deposit screening changes the moment of decision. In the reactive model, the question is asked late: “What do we do with funds already credited?” In the proactive model, it becomes: “Is it safe to accept this deposit at all?” In practice, this means that when an incoming transaction arrives, the system queries a blockchain analytics AML provider and retrieves a risk score for the address or transaction. This scoring accounts for address history, cluster associations, known entities, risk categories, and exposure depth. If the risk is within acceptable bounds, the deposit proceeds. If elevated, the transaction goes to additional review or is returned to the sender in line with the service’s policy.

In the case of Trustee Plus, the public-facing logic is built around a clear user scenario: funds are either credited, go through additional review, or are returned to the sender. The exception is cases where assets are identified as stolen and under active law enforcement investigation — in which case a regulated service is obligated to act within the framework of a judicial or law enforcement request. This model matters because it reduces uncertainty. Users don’t end up in a “regulatory limbo” where funds are already inside the product but inaccessible, with no clear timeline for resolution. For the company, it’s also better: incidents are handled at the entry point, before the risk propagates to other product operations — exchanges, withdrawals, card transactions, or settlements.

Six Layers of AML Architecture

A crypto product’s AML stack can’t be reduced to a single address check. It works only as a connected system. Using Trustee Plus as a case study, this architecture can be described across six layers.

1. Regulatory Perimeter

Trustee Plus clients are operationally served by a VASP. For a crypto product, this is an important foundation: VASP status defines the formal AML/CFT perimeter within which customer due diligence, transaction monitoring, sanctions screening, suspicious activity handling, and engagement with regulatory or law enforcement requests are structured.

That said, VASP status alone is only the foundation — not proof of AML effectiveness. Requirements differ significantly across jurisdictions (from basic registration to strict licensing), so regulators and banking partners can no longer be satisfied with abstract claims of “regulated” status. Real resilience only emerges when legal status is tightly integrated with product architecture: KYC, wallet screening, risk thresholds, audit trail, and defined handling scenarios for risky deposits.

2. KYC and Ongoing Monitoring

The second layer is Customer Identification. A basic KYC process includes document verification, liveness check, biometric matching, sanctions screening, and PEP screening. But for a crypto product, this isn’t enough.

KYC is a snapshot of the customer at onboarding. Customer risk changes over time: new sanctions lists emerge, transaction patterns shift, and users begin interacting with new counterparties or networks. That’s why the modern model is built around ongoing monitoring: regular reassessment of customer risk, transaction monitoring, and re-screening when behavioral patterns change.

3. Wallet Screening Before Credit

The third layer is pre-deposit wallet screening — the central element of the model. In the case of Trustee Plus, users have access to a public AML checker running on AMLBot infrastructure. It enables address verification before funds are sent and allows users to assess potential risks associated with the origin of crypto assets in advance.

Users can see a percentage risk assessment, risk sources, potential blacklist presence, cluster associations, balance, and transaction volume. Supported networks include BTC, TRX, and ETH. The key value of this tool lies in the ability for users to perform preliminary address verification themselves — avoiding situations where a transaction later triggers compliance review. Modern KYT systems work with risk categories and weights: sanctions, mixer exposure, darknet market, stolen funds, ransomware, scam, gambling, high-risk exchange, terrorist financing, and others. Threshold configuration depends on the company’s risk appetite, partner requirements, and jurisdiction.

4. Sanctions and High-Risk Entity Data

The fourth layer is maintaining current sanctions and high-risk entity lists. This isn’t a static table that can be updated once a year. OFAC, EU, UK, UN, and national sanctions lists change regularly. Law enforcement operations against mixers, darknet markets, and unlicensed exchanges create new risk clusters that must quickly enter the screening layer.

When OFAC adds another Hydra Market, Garantex, or Tornado Cash, a compliance team shouldn’t be updating databases manually. This is why deep integration with an external KYT provider — which maintains the full graph of sanctioned addresses, secondary linkages, and new typologies — is typically more effective than an in-house approach. The provider feeds new toxic clusters into the risk engine. The service (with its risk thresholds configured) automatically blocks a transaction before the user can accept a “dirty” transfer.

5. Risk Outcome and User Scenario

The fifth layer is what happens after a trigger fires. This is often the most underestimated part of AML architecture. For the user, what matters is not the fact of screening, but the predictability of the outcome.

The bad scenario: an indefinite freeze with no clear timeline or communication. The good scenario: a clear fork — the deposit is accepted, additional information is requested, funds are returned to the sender, or held only on legitimate legal grounds such as a stolen-assets investigation.

In Trustee Plus’s public material, this logic is framed as “credit or return,” with the exception of stolen funds under investigation. This is exactly the approach that makes AML not only a protective mechanism for the company, but a component of user trust.

6. Account Security

The sixth layer is account security. An AML stack is meaningless if a user account is easy to compromise. The basic security layer — encryption of personal data and access keys, PIN, 2FA, biometrics, device and session control — is not an add-on but part of the compliance perimeter. If an attacker gains account control, they can use the product for cashing out, withdrawal, or attempts to circumvent monitoring. AML and cybersecurity in crypto products cannot be treated separately.

Compliance as a Product Function

The most interesting aspect of the Trustee Plus case is the user-facing AML tooling. The public AML Checker on the Trustee Plus Website — built on AMLBot infrastructure — transforms AML from a hidden back-office process into a tool users can access themselves. They can check an address before sending funds or before accepting a transfer.

This changes the perception of compliance. In the traditional model, AML is associated with blocks and inconvenience.

In the product model, AML becomes a tool for self-protection: users see risk scores, understand the sources of risk, and gradually begin thinking in terms of exposure. 

What the Industry Can Take From This Approach

The Trustee Plus case is useful not because it’s unique, but because it shows where the market is heading. For most wallets, crypto cards, and retail neobanks, five conclusions apply:

• Pre-Deposit Screening Should Become The Standard. The later a company detects risk, the more expensive the incident. Screening before credit reduces churn, support load, and the likelihood of downstream problems with partners.
• Sanctions Hygiene Is Infrastructure, Not A One-Time Project. Lists and risk clusters change constantly, so integration with a KYT provider is typically more effective than trying to maintain everything in-house.
• KYC Without Transaction Monitoring Is Insufficient. A user can pass a clean onboarding and later begin interacting with risky counterparties. Monitoring must be continuous.
• User-Facing AML Tools Are Undervalued. A free wallet checker raises AML literacy among your audience and reduces the likelihood of accidental interaction with high-risk addresses.
• Regulatory Status Must Be Described Precisely. In global crypto regulation, VASP registration, licensing, transitional regimes, partnership models, and actual operational scope cannot be conflated. For product credibility, legal formulation must be as precise as technical architecture.

Conclusion

Crypto products will no longer compete on the number of supported networks, cashback rates, or card convenience alone. These parameters are becoming table stakes. The new differentiation layer is trust architecture: how deeply compliance is embedded in the product, how quickly the service detects risk, how transparently it responds to triggers, and how predictable the user outcome is. Pre-deposit screening, current sanctions data, ongoing monitoring, user-facing AML tooling, and a predictable policy for handling risky deposits are becoming baseline elements of a serious crypto product. Trustee Plus demonstrates one version of this model: AML not as a post-facto block, but as a built-in decision layer before risk enters the product at all.

For the industry, this is a direction. Regulators will demand more proof, banking partners will require more operational discipline, and users will expect more transparency. Products that embed compliance into their architecture in advance won’t look more “over-regulated” — they’ll look more reliable.

-AMLBot & Trustee