Payment account and balance risk in electronic money institutions

In electronic money institutions, money laundering risk is concentrated in the balance accumulating in the account and the pattern between top-ups and withdrawals, rather than in a single transaction. Institutions are obliged parties under Law No. 5549; their operational regulator is TCMB.

Where does risk accumulate?

Electronic money institutions are obliged parties under Law No. 5549 on Prevention of Laundering Proceeds of Crime. MASAK publishes a joint suspicious transaction report guide for payment and electronic money institutions and expects reports to be submitted electronically via MASAK.Online.

The common feature of the types related to payment accounts in the sector-specific section of the guide is that they are defined by looking at the account's behavior over time, rather than looking at a single transaction.

T-006-2.66 considers a sudden and significant change in the balance of a payment account compared to its long-term average as an indicator of suspicion. To meet this type, the account history must be stored and compared; a simple real-time threshold check is not enough.

Which indicators does the guide list?

The top-up side

T-006-2.62 is particularly striking: it requires IP data to be collected and stored at onboarding and compared across accounts. If this data is not captured at that moment, it cannot be generated later.

The withdrawal side

T-006-2.60 lists topping up an inactive payment account and then withdrawing those funds, usually via maximum cash withdrawals from ATMs, while T-006-2.69 lists transferring funds deposited into payment accounts from ATMs in different provinces to the electronic money account holder's bank account via EFT.

On the prepaid card side, T-006-2.26 considers continuous cash withdrawals of conspicuous amounts from the card as an indicator, while T-006-2.27 points to the continuous or conspicuous use of the card for purchasing precious goods that are easily convertible to cash, such as gold. The latter cannot be analyzed without merchant category data: without knowing where the card is spent, it is impossible to know what was purchased.

Structuring

T-006-2.8 lists customers splitting money into multiple accounts, wire transfers, or cash to avoid reporting procedures, and it also covers attempted transactions. This means an unexecuted transaction can also be subject to reporting; the system must store rejected and incomplete transactions as well.

T-006-2.5 adds the splitting of financial transactions that should normally be carried out in bulk, without a logical justification, to avoid detection and reporting.

What does the reporting form require?

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

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 reporting, the suspicion is placed into one of the categories in MASAK's reference table, and each category is mapped to the relevant legal regulation. This means case management must work 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 documents or serious indications supporting the suspicion that the assets subject to the transaction are related to money laundering or terrorist financing, and these must be submitted along with the justifications.

This threshold directly generates 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.

Where does the data reside?

Electronic money institutions are regulated and supervised by both TCMB and BDDK. This makes where the monitoring software runs and where customer data goes an auditable matter.

TruvaLI supports on-premise deployment: the software runs on the institution's own infrastructure, customer data remains within the institution's information systems, and keys and the audit trail are under the institution's control.

How does TruvaLI address this?

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, provider lists, the address's association with the person's name and date of birth, and fuzzy comparison with 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.

These scores remain in the customer record and serve as inputs for subsequent rules. Types like T-006-2.62, which link accounts of different individuals via the same IP, cannot be met without this data.

Monitoring account behavior

The rule engine supports nested logic and flexible aggregation windows, meaning rules defined as "based on the account's last 90-day average" are set up within a single rule. For types requiring comparison with history, such as T-006-2.66, the institution's own policy determines the threshold.

Attempted and rejected transactions are also stored, because T-006-2.8 also covers attempts.

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

Relationship network

A connection network between accounts is extracted via shared IP, device, phone, and email. Types that consolidate multiple accounts into a single point, such as T-006-2.4 and T-006-2.62, cannot be detected through individual account checks.

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 a total, and can generate separate clusters based on the channel. The suspicion category is selected from MASAK's taxonomy.

Evidence and decision justifications are written to an immutable audit trail, the second-pair-of-eyes approval runs via maker/checker, and the documents and justifications 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.

The counterpart on the payment services side is on the payment institutions page. Relevant flows: customer onboarding, ongoing monitoring, remittance, and regulatory reporting. The framework is on the MASAK obligations page, and deployment is on the on-premise deployment page.

Source

MASAK, "Suspicious Transaction Reporting Guide for Payment Institutions and Electronic Money Institutions", MSK-RHB-ŞİB-006, version 2.0.

This page is not a regulatory 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.