Sanctuary: how AML checks help avoid accepting problematic crypto

Sanctuary is an AML service for checking crypto wallets, the origin of funds, and risky connections on the blockchain. It helps P2P traders, OTC desks, exchangers, and businesses spot a problem before funds reach a wallet or enter operational flow.

You can accept a transfer, complete a deal, mix those funds with other assets, and then, a week or a month later, receive a freeze from an exchange or a request from a bank. In that situation, what matters is not only the risk score itself, but a clear explanation: where the risk came from, which sources confirm it, and whether this can be shown to a compliance department, partner, or counterparty.

Kursoff spoke with the Sanctuary team about why the market no longer has enough of a simple number like Risk: 85%, how cryptographically signed reports work, why P2P traders remain one of the most vulnerable groups, and how checking funds is gradually becoming basic hygiene for everyone who regularly works with crypto payments.

Who is behind Sanctuary? Tell us about your team and your background in crypto security and blockchain analytics.

Behind the product is Sanctuary Compliance Digital Ltd, a company registered in England and Wales. For us, this is an important detail because in this field, a client should be able to verify not only a wallet, but also the service they trust with decisions about their money. The company registration number can be checked in a minute, and any of our reports can be verified through a public link without registration.

Our team is small and non-public. This is not about modesty, it is about security. People who label wallets linked to scammers, sanctioned services, and darknet markets inevitably come into the field of view of those they label. In this line of work, publicity does not always help, but it definitely creates additional risks.

We do not build trust on biographies or loud titles. A line about ten years in blockchain analytics does not make a check more accurate on its own. What matters much more is that we came to this problem from the operator’s side, not from the side of a classic vendor. From the side of a person who has to make a decision about someone else’s transfer within minutes, and six months later explain that decision to a bank or partner.

That is why the product was built around several key things: evidence instead of a bare number, honest coverage instead of a pretty green screen, and a signed report instead of a screenshot. We also do not have a long chain between the people who write the risk scoring logic and those who investigate false positives. If a user shows us a problem, it quickly reaches the team that can actually fix it.

In numbers: in less than two years, we have built our own intelligence layer with 158 data sources, almost 62 million labels and flags, 179.8 million addresses, 19.9 million behavioral clusters, 42 entity types, and 16 behavioral detectors. The system returns a verdict in about two seconds across three interfaces: Telegram bot, dashboard, and API.

If you had to explain Sanctuary to someone far from the crypto world, how would you describe your service in a few sentences?

Imagine you are buying a used car. Before buying it, you check whether it has been stolen, whether it is pledged as collateral, whether it has been in serious accidents, and who owned it before. Sanctuary performs a similar check, but not for a car, for crypto funds.

On the blockchain, the path of coins is visible: which wallets, services, and addresses they passed through. We analyze this path before a person accepts a transfer and show whether those funds have a problematic history.

For an ordinary user, this has a very practical purpose. If funds that were previously linked to a hack, fraud, or a sanctioned address arrive in a wallet, an exchange may freeze the account during withdrawal. Not because the person is a criminal, but because an asset with a risky origin ended up on their balance. A check in advance takes a few seconds, while dealing with a freeze afterward can take weeks.

What was the spark that made you realize: that’s it, we need to build our own AML tool?

The spark was not one specific loss of money. We kept seeing the same situation again and again: a person accepts a transfer, completes a deal, and then, after some time, gets frozen. Then they go to an AML service, pay for a check, and see only a number. For example, Risk: 78. But what does 78 mean? Where did the risk come from? Which source confirmed it? How close is the connection to the problematic address? When did it happen? No one explains this properly.

At some point, it became clear: this is not just a technical problem. This is a product choice. When a verdict is not explained, it is hard to challenge. A person is left with a number, but without a document they can take to an exchange compliance department, a bank, or a counterparty.

That is why we did not start with the technical side, but with the final document. We first defined what a report should look like if it is going to be used in a real dispute. It has to be signed, contain a snapshot of the address state at the moment of the check, include a public verification link, and show how many sources actually responded. We built the product logic around that document.

In short: what bothered us was not the fact that people get blocked. Blocks will always exist, because that is part of compliance work. What bothered us was something else: people often never get an explanation of why they were blocked.

Who is your main user today: P2P traders, private crypto investors, OTC desks, or full-scale Web3 businesses?

By number of users, it is P2P traders and small OTC. By volume, it is exchangers, OTC desks, and platforms that accept incoming crypto payments.

These are different scenarios, so we do not mix them together. A P2P trader needs a quick check before a deal. They work from a phone, in Telegram, between messages with a counterparty. They do not need a large dashboard. They need a clear answer before they release crypto or fiat.

An exchanger or OTC desk needs a different logic: an API for incoming payments, a risk threshold after which a transaction goes to manual review, a watchlist for regular counterparties, and a check log that can be shown to a bank or partner months later. Here, the value is not in the number of checks, but in the incidents that were avoided.

Private investors also use the service, but they are not the main focus. We are building a product for those who have a regular flow of deals, dozens of counterparties, and the risk that one mistake can freeze a significant part of their turnover.

There are already several well-known AML services on the market. What is your main feature and strength that makes users choose Sanctuary?

Our first key difference is that we do not sell a feeling of safety where there is not enough data. In every check, users can see how many sources responded and how many did not. If coverage for a certain network or address is limited, the report says so directly. We do not turn the phrase we found nothing into this is definitely clean. These are different things, and for the user the difference is critical.

The second strength is evidence: every check shows not only the risk assessment, but also the logic behind it: entity type, sources, confidence level, distance to the risky point, share of funds, and coverage status. The report is cryptographically signed, so it can be sent to a counterparty or compliance department and verified through a public link.

Third: one engine works across the Telegram bot, dashboard, and API. This means that a P2P trader using a phone and a business with a technical integration receive the same intelligence, just through different interfaces.

Another part of the value is the shared intelligence layer. If one merchant confirms a fraudulent wallet, this information can help another user who encounters the same cluster a few days later. The database is constantly growing: it includes 158 sources, almost 62 million labels and flags, 42 entity types, 179.8 million addresses, and 19.9 million behavioral clusters.

A database like this cannot be quickly bought or copied. It can only be accumulated day by day. That is why a new empty wallet does not automatically look clean to us: if there is a risky cluster behind it, the system will take that into account.

Most people learn about dirty crypto only after their exchange account gets blocked. How does Sanctuary shift the approach from damage control to checking before funds move?

The problem is that most people start checking funds only after an incident. But after a freeze, the user is no longer making a decision. They are trying to explain what has already happened. This is longer, more expensive, and often much more stressful.

We try to move the check to the moment before the deal. While the funds have not yet been accepted, the user still has a choice: proceed with the operation, ask for another address, refuse the deal, or send it for manual review. After the transfer, that room for maneuver is gone.

For P2P, this is a quick check in the bot before a deal. For an exchanger or platform, it is automatic screening of incoming payments. A suspicious transaction is not credited immediately, but goes to additional review. For regular counterparties, there is a watchlist: if the risk changes after new data appears, the system notifies the user.

It is impossible to remove freezes completely, because the final decision is always made by an exchange, bank, or another platform according to its own rules. But it is possible to make sure that a person does not accept funds blindly and has evidence that they checked the risk before the deal.

P2P traders and OTC desks are among the most vulnerable groups. Have clients come to you with particularly absurd or complicated account freeze cases?

We do not publish specific addresses or client stories, even in anonymized form. But the typical scenarios repeat very often.

First scenario: a person is effectively punished for someone else’s history. They sell USDT, receive payment, and the funds come not directly from a scammer, but through several intermediaries. Formally, the address has exposure to risk, although the person may not have known about it and had no relation to the original incident.

Second scenario: an exchanger or service works with a shared hot wallet. One client honestly buys crypto but receives funds from a wallet where different flows, including problematic ones, had previously been mixed. As a result, the risk moves on to the end user.

Third scenario: the user consolidates funds themselves. For example, they kept different incoming funds on different addresses and then brought everything into one wallet before withdrawal. If there was a problematic flow among those incoming funds, one address now looks like a wallet with a combined risky history.

There is also a separate situation with random incoming transfers. A person did nothing, but toxic tokens or a small transfer were simply sent to their address. Good analysis should distinguish passive receipt from intentional interaction, but automated systems do not always read the context finely enough.

What most often makes a wallet dirty in 2026? Is it always a connection to darknet or sanctioned services, or can it be a simple chain of random transactions?

Darknet and sanctioned addresses are not the only, and not even the biggest, cause of risk. In 2026, most problems look much more ordinary: fraud, hacks, scams, stolen funds that pass through several intermediate wallets, exchangers, or bridges.

The highest risk is created by funds that were already connected to thefts, phishing, account hacks, or other schemes. They rarely stay in one place. They are split, moved, bridged across networks, converted into stablecoins, and gradually brought into ordinary circulation. This is how risk can reach a person who had nothing to do with the original crime.

Stablecoins, especially USDT, are particularly important here. They are used because of their speed, liquidity, and clear value. For P2P traders and exchangers, they are an everyday tool, but that is exactly why problematic flows often pass through them too.

Another factor is cross-chain bridges. When funds move from one network to another, the trail becomes more complex. In the old network, you can see the entry into the bridge. In the new one, an asset appears that already looks different. Anyone analyzing only one network can lose part of the history.

It is important to understand that a dirty wallet is not always a black-and-white status. The share of risky funds, the distance to the problematic source, and the age of the connection all matter. A direct incoming transfer from a risky address yesterday and a small exposure through several intermediate steps three years ago are different levels of risk.

You promise analysis across 12 networks and a verdict in under 3 seconds. How is the aggregation of on-chain behavior data technically organized to achieve this speed without losing accuracy?

First, it is important to clarify the wording. Full analysis currently runs across ten core networks: Bitcoin, Ethereum, TRON, BNB Chain, Solana, TON, Polygon, Arbitrum, Optimism, and Base. Around twenty more EVM networks are covered by screening with fewer sources, and we mark this directly in the report. In total, the system covers more than thirty networks.

The speed does not come from the system taking a superficial look at the address at the moment of the request. The heavy work happens in advance: entity labeling, address clustering, connection analysis, and database updates run continuously in the background. When a user starts a check, the system does not begin the investigation from zero. It queries a prepared data layer.

External sources are queried in parallel. Each source has a time limit, so a slow response does not block the entire result. A typical check is assembled in about 1.5 to 2 seconds.

At the same time, we do not hide incomplete coverage. If some sources did not respond or there is less data for a specific network, the report shows this. Speed should not create an illusion of accuracy where there is not enough data. Deep graph tracing can take longer, and we do not present it as the same two-second check.

Many AML services provide only a risk score, for example Risk: 85%, but do not explain why. Why did you focus on cryptographically signed reports with evidence?

Because a number without an explanation is almost useless when a real dispute begins.

A risk score is useful for a quick decision, but it is not enough for a conversation with an exchange, bank, or compliance department. If a person says that a service showed Risk: 85%, this does not answer the main question: is the risk related to sanctions, a hack, a mixer, old indirect exposure, or weak source coverage?

That is why our report shows not only the assessment, but also the logic behind it. It shows which entity type was identified, which sources triggered, how confident they are, what share of funds is linked to risk, what the distance to the problematic source is, and how complete the check itself was.

The cryptographic signature is needed so the report can be verified. The document has a hash, an Ed25519 signature, and a snapshot of the address state at the moment of the check. If the data changes a month later, the report still shows exactly what the user saw on the day of the deal. This matters not as a nice technical detail, but as a way to protect a position: the person can prove that they checked the funds before making a decision.

How do compliance departments at major CEX exchanges react to your signed PDF reports when a user disputes a freeze? Are there successful unfreeze cases?

No AML report can force an exchange to unfreeze funds by itself. That is not how it works with us or with any other service. The decision always remains with the exchange, bank, or platform conducting its own compliance review.

But a high-quality report can change the conversation significantly. When a user writes I did not violate anything, that is an emotion. When they provide a document with a date, sources, an explanation of fund origin, and a signature that can be verified, it becomes material for review. Especially if the check was done before the deal, not after the freeze.

We have several typical cases.

1. A P2P group of 12 traders. Before working with us, they had four account freezes in three months, each blocking between $15,000 and $50,000. After pre-trade checks, a watchlist, and an internal rule for high-risk addresses, they had no new freezes over six months.
2. A European OTC desk with more than $2 million in monthly turnover. Before the integration, the team checked counterparties manually and without proper documentation. After connecting the API, every address is checked before a deal, suspicious payments go to manual review, and reports can be shown to the bank.
3. A small exchange with 5,000 active users and a licensing process in Singapore. The team needed screening, monitoring, and evidence records. The API was integrated in two days, after which deposits and withdrawals started being checked automatically.

There was also a case with law enforcement in Eastern Europe. In Q4 2025, our data helped trace and freeze funds from a P2P triangle scheme. In total, $420,000 was recovered. The details of the case are not disclosed publicly, but for us it is a sign that the evidence part of reports can work not only within exchange compliance.

How does your Entity Context assessment differ from risk assessment in classic systems like Chainalysis or Elliptic?

The classic approach often answers the question: what share of funds is linked to a certain risk category. This is the right question, but it is not enough. Very often, the user does not see a scary red signal, but something less definite: no risk found, but it is unclear what kind of address this is.

We place a strong emphasis on entity context. We want to answer unknown wallet as rarely as possible. To do this, addresses are grouped into behavioral clusters, and entity types are applied on top of them: exchange deposit address, exchanger hot wallet, service address, risky cluster, and so on.

For an operator, this is critical. An address with no detected risk but an unknown nature is one scenario. A deposit address of a major exchange with no risk is a completely different scenario. In the first case, caution is needed. In the second, the user can work much more calmly.

Another difference is that behavior alone does not pass judgment. A suspicious transaction pattern can raise attention, but without confirmation from external data, it should not automatically make an address critical. This helps reduce the number of false positives.

Are there false positive cases when a clean wallet receives a high-risk verdict, and how do you deal with them?

Yes, such cases happen in any AML system. If someone says they have no false positives at all, they either do not measure them or are not telling the whole truth.

The problem most often appears with wallets of large services. For example, a deposit address of an exchange or exchanger can see thousands of different incoming transfers, and some of them will inevitably be risky. If such an address is assessed as a personal wallet, the system may mistakenly assign it a high risk.

To avoid this, we first determine the entity type. If an address belongs to a service, it is not assessed by the same logic as a private wallet. Behavioral signals also do not work as a final verdict. A suspicious pattern without confirmation from other sources cannot independently move an address into the critical zone.

The product has a way to report a false positive. This is not just a support form, but a separate review process. The request goes to an analyst, has a status, and the user can see what is happening with it. For us, these reports are not a reputational problem, but a way to improve the system.

Our principle is simple: it is better not to place a label than to place one on an innocent user. Excessive strictness may look safe for the service, but for the user it can sometimes mean frozen funds.

How does Sanctuary protect its own system from attackers trying to test their dirty wallets and adjust their schemes to your algorithms?

In a public format, we cannot disclose technical details that would help bypass the system. But the general logic is this: we analyze not a single address, but connections, clusters, and the origin of funds.

If funds came from an address linked to a hack or fraud, creating a new empty wallet does not make them clean. The connection can become longer, but the history of the funds does not disappear. That is why the system looks wider than just the current address.

We also do not build a verdict on one signal. Bypassing one source should not break the whole assessment. Part of the logic is not exposed externally so it cannot be mechanically adjusted. Data is updated daily, so the result of a check can also change after new information appears.

Access to checks is controlled, paid, and rate-limited. Mass probing of the database leaves traces and does not look like normal user behavior.

No one has absolute protection against attempts to adapt. The realistic goal is different: to make bypassing the system more expensive, slower, and less predictable than the potential benefit from doing so.

You have both a classic API for businesses and a Telegram bot. Who is your main Telegram user, and is it convenient to check wallets on the go before a P2P deal?

The main users of the Telegram bot are P2P traders, arbitrage traders, small exchangers, and OTC operators who work from a phone. It is not a simplified version of the product. It is the same product logic, just in an interface that is convenient for a deal.

The scenario is simple: the counterparty sends an address, the trader copies it into the bot, and receives a verdict before releasing crypto or fiat. There is no need to enter a dashboard, open complex menus, or remember commands. Everything works through buttons.

We built the bot precisely because many P2P decisions are made in messengers and very quickly. If a tool does not fit into those few minutes, people simply will not use it. The first check is available without registration, and every user has one free check per day. Sanctions list screening is included even in the free check.

Can a regular freelancer or online business integrate your API to automatically check incoming payments from clients?

Yes, the integration is quite simple. The business sends the sender’s address and receives an assessment, risk level, and breakdown in response. There is a fast method for preliminary checking and a full format when evidence and a report are needed. The network is detected automatically, so it does not have to be specified separately.

For small businesses, we usually recommend three basic rules: check the payment before crediting the service or shipping the product, set a risk threshold for manual review, and store reports for all significant payments. Questions about the origin of funds often come not at the moment of receipt, but months later, when a bank or partner asks for an explanation.

For those who do not have a developer, there is an option without the API: manual checks in the dashboard or Telegram bot, plus a watchlist for regular clients. If the risk for an address changes, the system will notify the user.

The API plan starts at $199 per month for one thousand checks. For a freelancer with a few payments per week, this may be too much, and the bot will be enough. For a store, service, or exchanger with a payment flow, it is cheaper than one serious incident with a frozen withdrawal.

The line between blockchain transparency and the right to financial privacy is becoming thinner. How does Sanctuary balance deanonymizing risky entities with protecting personal data?

For us, the line is simple: we do not deanonymize people, we analyze addresses, services, and the behavior of funds.

A statement like this address looks like an exchange deposit address or this address received funds from a sanctioned source does not contain a name, passport, IP address, or other personal data. We do not link wallets to specific people and we do not buy such data.

In the intelligence database, addresses are stored in pseudonymized form. This was built into the product architecture from day one. To check a wallet, the user does not need to pass KYC. In the Telegram bot, the first check is available even without registration.

The company is registered in England and Wales and operates as a data controller under UK GDPR. For business clients, there is a standard data processing agreement. Where the law or a payment scenario requires storing an address in open form, we state this directly in the documentation.

Our position is this: the privacy of an ordinary user and the transparency of criminal infrastructure do not contradict each other. The problem begins when a company collects more information about the user than it actually needs for its work.

Transfers through cross-chain bridges, L2 networks, and mixers are becoming increasingly complicated. Which of the 12 networks you support are currently the hardest to track, and why?

The hardest thing today is not a specific network, but the transition between networks. Funds enter a bridge on one blockchain and exit on another as a different asset. Formally, the trail breaks: in one network, you see a transfer to a contract, and in another, new funds appear. We can connect such events by amount, time, and behavior, but this is probabilistic work, and we do not present it as an absolute fact.

Bitcoin is difficult because of the UTXO model. One user may have many addresses, and change from their own payment may look like a separate transfer to another person. Without quality clustering, Bitcoin analysis easily becomes superficial.

TON is difficult because of its younger data infrastructure. There are fewer mature public tools than around Ethereum, so some solutions have to be built internally.

Solana is difficult because of its activity volume and the specifics of token accounts. A naive reading of transfers can produce a distorted picture if the network structure is not taken into account.

Another category includes mixers, private bridges, atomic swaps, zero-knowledge services, and channels built on top of Lightning. If the system sees interaction with such tools, it has no right to simply say safe. Where tracing is technically limited, we explicitly limit confidence in cleanliness.

Do you plan to go beyond 12 networks, and which new blockchains or L2s are currently the highest priority for integration?

Right now, our priority is not the number of networks, but the depth of analysis in the networks where users’ money actually moves.

Adding a new network to a marketing list is not difficult. The problem is that for many services, support for dozens of networks in practice means only a basic check against sanctions lists. The user sees a green screen and thinks they received a full check, although the data may be very limited. This is more dangerous than honestly saying: coverage here is limited.

Our nearest priorities are deeper Bitcoin analysis, stronger attribution on TRON, and a more complete set of sources for L2 networks around Ethereum. Bitcoin requires complex clustering, TRON is important because of the large USDT flow, and L2s are gradually taking more and more real payments.

We will add new networks not because they are trendy, but when we see a real flow of funds from our users there. For us, it is more important to honestly show the quality of coverage than to have a long list in a comparison table.

In a broader sense, we are moving toward a world where checking the origin of funds becomes an invisible base layer for any crypto payment. Like an antivirus that checks a file without being asked separately. In a few years, accepting funds without an AML check may look as strange as a website without encryption looks today.

What should an ordinary user do if toxic tokens arrive in their wallet through an airdrop or a random transfer from an unknown sender?

The first and most important thing: do nothing. Do not send them, do not sell them, and do not connect your wallet to the website attached to the token. Such distributions often exist precisely to make the person take the next step: sign an approval, visit a phishing site, or try to sell an unclear asset.

The fact of an incoming transfer alone does not mean the person is involved in a scheme. Good analysis should distinguish passive receipt from intentional interaction. But automated systems can be rougher, so it is better to record the situation immediately.

Do not mix such funds with your main wallet. If a toxic asset arrived at an address, you should not later consolidate everything from that address into your main wallet. Otherwise, someone else’s history may move along with the funds. It is better to run a check, save a dated report, and not touch the suspicious asset.

Separately, about dust attacks: small unclear incoming transfers are often used not for direct theft, but to link a user’s addresses together through their reaction. The best reaction in such a situation is not to react.

What is the most common misconception about crypto wallet checks that the market still believes?

The first misconception: if an address was checked once, it is clean forever. In reality, a check is a snapshot of the state at a specific moment. A counterparty can look clean on Monday and receive a label on Thursday because a source published new data about an old hack or fraud scheme.

The second: if the service shows zero, everything is definitely fine. Zero may mean not we confirmed cleanliness, but we found nothing. These are different things. If there are few sources for a network or some sources did not respond, low risk should not be treated as an absolute guarantee.

The third: a risk assessment is a verdict. A score of 60 or 70 does not by itself mean that an address is criminal. It means the context needs to be reviewed: sources, distance, share of funds, entity type, and age of the connection. That is why we focus not on a single number, but on an explanation that can be verified and defended.

What is the one main piece of advice you would give to someone who is just starting to actively operate with large amounts in crypto?

The main advice is to separate flows and check funds before the deal, not after.

Do not keep everything on one address. It is better to have a separate wallet for new counterparties, another for trading, and another for storage. If a problematic asset arrives at one address, it will not ruin the entire history of your funds.

You need to check before you give away your funds or release goods. This is the only moment when you can still calmly refuse the deal, ask for another address, or send the transaction for manual review. After the transfer, it is no longer a check, but an attempt to deal with the consequences.

And it is essential to keep evidence. Every significant deal should leave behind a report with a date. Questions about the origin of funds may appear months later, when no one remembers the details anymore. A person with an archive of checks and a person with the phrase I definitely did not violate anything are in completely different positions.

In crypto, there is no bank that can simply cancel a mistaken payment, and no service that will return money based on a request. The cheapest protection is a check before the deal. Fifteen seconds before a transfer cost less than any investigation after a freeze.