MASAK compliance and wallet risk for crypto asset service providers

Crypto asset service providers are obliged parties under Law No. 5549, and their operational regulator is SPK. The distinguishing aspect of the sector is the shift in the screened entity: alongside the individual's name, the wallet address itself is an entity, and the history of the address is the subject of screening.

Who is obliged, and how does the process work?

Crypto asset service providers are obliged parties under Law No. 5549 on Prevention of Laundering Proceeds of Crime. MASAK publishes a separate suspicious transaction report guide for this group and expects reports to be submitted electronically through the MASAK.Online system.

The guide does not only answer the question of "which transaction is suspicious". It also defines which fields the reporting form will contain, which reference tables will be used to code the transactions, and which category the suspicion will be placed under.

Which indicators does the guide list?

Who is the screened entity, the address or the individual?

In the guides of other sectors, screening is performed on the customer. In the crypto guide, there is an additional step: the address itself is also a screened entity.

T-010-2.8 considers attempting to transfer to individuals or addresses on lists of banned, suspicious, or wanted persons published by national and international authorized bodies as an indicator of suspicion. This means that the sanctions screening workflow must accept the wallet address alongside the individual's name.

T-010-2.27 lists fragmented transfers made to the same crypto asset address by different customers within a certain period. This type cannot be detected by looking at a single customer's account: it requires aggregating the behavior of multiple customers around the same destination address.

Anonymity indicators

All four ask the same question: can the identity of the counterparty be known. This requires the address and the platform to be classified; it cannot be answered simply by looking at the transaction amount.

Off-exchange channels

T-010-2.54 lists the customer making continuous and high-value transfers through peer-to-peer (P2P) platforms, while T-010-2.71 lists continuous and high-value trading through over-the-counter (OTC) markets. T-010-2.59 adds frequent and high-value deposits and withdrawals from crypto asset ATMs.

These three show that the risk lies not only within the platform's own ledger, but also in the customer's behavior outside the platform.

Account's own behavior

T-010-2.9 lists high-value transfers arriving in the customer's account shortly after account opening, followed by a long period of inactivity with the transferred funds. T-010-2.13 adds depositing large amounts of fiat or crypto assets into an account with a very low balance and withdrawing them at certain intervals.

T-010-2.66 considers large-volume purchases and rapid sales of crypto assets whose value rapidly increases or decreases in a short period as an indicator, while T-010-2.61 lists purchasing high-value NFTs followed by their sale.

T-010-2.23 stands under a separate heading: the customer performing transactions like a crypto asset service provider without declaring their activity. In other words, whether a customer is actually acting as an intermediary is also something that must be monitored.

Data at the time of onboarding

T-010-2.17 lists opening accounts and executing payment transactions using addresses from untrusted email servers. T-010-2.2 covers seemingly independent customers providing the same address, phone number, or similar contact details, and having trading relationships with the same individuals.

Both rely on data collected at the time of onboarding. Email and contact data not captured at that moment cannot be generated later.

What does the reporting form require?

Suspicious matters that do not contain monetary value are written in the explanation section of the form, not the suspicious transaction section. This means a case must also be able to carry non-monetary events.

A report can be based on a single transaction or on multiple transactions within a specific date range: in the case of multiple transactions, the total amount and date range are reported together. If suspicious transactions are concentrated in different channels or types, the form section can be repeated for each cluster.

How is the suspicion category selected?

When making a report, the suspicion is placed into one of the categories in MASAK's reference table, and each category is matched with the relevant legal regulation. The list ranges from cybercrimes to fraud, tax evasion to the violation of asset freezing decisions.

This means that case management must operate with this taxonomy rather than its own free-form tags.

What is the threshold for reports with a suspension request?

The regulation based on Article 19/A of Law No. 5549, titled "Suspension of transactions", regulates the suspension of transactions based on a report. The guide sets a clear threshold for this: rather than mere suspicion, there must be supporting documents or serious indications that the asset subject to the transaction is related to money laundering or terrorist financing offenses, and these must be submitted along with the justifications.

This threshold directly creates a system requirement: evidence must be attached to the case, the justification must be written, and the person who made the decision must be recorded.

How does TruvaLI address this?

The address is also a screened entity

Sanctions, PEP, and internal list screening accept the wallet address alongside the individual's name. The institution can create its own blacklists and address lists: lists can be automatically extracted by providing a website address or established by uploading official documents. T-010-2.8 cannot be met without this structure.

Data collected during onboarding

In remote identity verification, document chip reading, liveness, and face matching run in a single flow. Simultaneously, email and IP scores are calculated: on the email side, fuzzy comparison with provider lists and similar addresses in the system; on the IP side, location with ip2location, ownership with RIPE, and whether it is a proxy or VPN with rDNS. T-010-2.17 and T-010-2.2 rely on this data.

Convergence of on-chain and off-chain data

Wallet address, counterparty, and third-party risk tags come from the institution's own systems or integrated data sources and are linked to the customer record. Field mapping is dynamic, connecting without changing the institution's data model.

Rule engine and relationship analysis

Types in the guide are converted into rules: with nested logic, flexible aggregation windows, and callbacks from rules. Time-dependent rules, such as "withdrawal to an anonymously classified address within two hours of deposit", are set up in a single rule.

A relationship network among customers is extracted via shared IP, device, contact details, and destination address. Types like T-010-2.27 that aggregate multiple customers around the same address cannot be detected through individual account checks.

Before deploying a new rule to production, you can test it in rule simulation on historical traffic to see the alert volume it will generate. You can describe the rule in your own language using a prompt and approve the draft.

Case, evidence, and category

An alert turns into a case with an owner, duration, and evidence. The case also carries non-monetary events, can present transactions within a date range as an aggregate, and can generate separate clusters based on the channel. The suspicion category is selected from MASAK's taxonomy.

Evidence and decision justification are written to an immutable audit trail, second-pair-of-eyes approval runs via maker/checker, and the documents and justification required for reports with a suspension request are attached to the case. The report draft is prepared from the same case data, and the signature remains with the institution.

Related workflows: crypto wallet screening, customer onboarding, source of funds investigation, ongoing monitoring, and regulatory reporting. On the European Union side, crypto asset service providers are under direct supervision: AMLA and EU regulations. The framework is on the MASAK obligations page.

Source

MASAK, "Suspicious Transaction Reporting Guide for Crypto Asset Service Providers", version 2.0.

This page does not constitute legal interpretation; it conveys the indicators and procedures listed in the guide. Rules, thresholds, and actions are configured according to the institution's own risk policy and obligations.