MASAK compliance and transaction monitoring in banking

The obligation to combat money laundering in banking consists of the know-your-customer, transaction monitoring, and suspicious activity reporting chain under Law No. 5549. MASAK's suspicious transaction reporting guide for banks lists sector-specific indicators individually, and most of these indicators cannot be seen from a single system: they require reading customer, account, transaction, and channel data together.

Who is obliged, and how does the process work?

Banks and, limited to banking activities, PTT are obliged parties under Law No. 5549 on Prevention of Laundering Proceeds of Crime. MASAK publishes a separate suspicious transaction reporting guide for this group and expects reports to be submitted electronically via the MASAK.Online system.

The scope of the guide is not limited to the question of "which transaction is suspicious". It also defines which fields each section of the reporting form will carry, which reference tables will be used to code transactions, and which category the suspicion will be placed in. This directly determines the output a bank expects from its monitoring software.

Which indicators does the guide list?

The distribution of the 112 banking types, which is the largest group, determines the monitoring structure a bank must establish: 41 relate to transfers and wire transfers, 18 to cash and structuring, 19 to digital channels, 12 to loans and collateral, and 9 to card and ATM transactions.

Why are indicators not visible from a single system?

Reading the types in the guide and looking at what data is required shows why the issue does not end with simply purchasing a monitoring product.

When these four are read together, the conclusion is clear: the real question for a bank is not which monitoring product to buy, but how fully integrated the product can be with core banking and peripheral systems. The safe deposit box access log resides on the branch side, while the financial transaction sits in core banking: without bringing the two together, T-001-3.95 will never be triggered.

Linked accounts

T-001-3.7 groups under a single type customers who seemingly act independently but provide the same address and phone details, send transfers to the same beneficiaries, receive transfers from the same originators, or grant signature authority on their accounts to the same individuals.

Four signals reside in four separate places: contact information in customer master data, beneficiary and originator details in transfer records, and signature authority in the account opening file. Single transaction checks do not link any of these together.

T-001-3.16 lists numerous individuals depositing money into the same account without a reasonable explanation, or transfers being made from many separate accounts to the same account. This requires mapping the network around a single account.

Structuring, cash, and occupation as a reference

T-001-3.14 lists customers splitting money into multiple accounts, transfers, or cash to evade reporting procedures, and it also covers attempts. This means an unexecuted transaction can also be subject to reporting: the system must also store rejected and incomplete transactions.

T-001-3.18 considers the inability to relate cash movements in accounts to the customer's standard of living, occupation, and income level as an indicator. This shows that occupation and income declarations are not fields collected and forgotten at onboarding: they are references compared against every transaction. T-001-3.2 already lists difficulty in obtaining activity, occupation, or identity, address, and phone details from the customer as a separate type.

What does the reporting form require?

The guide defines the sections of the reporting form and the fields of each section. This is the output that the monitoring software must produce.

Suspicious matters that do not contain monetary value, such as suspicious account openings and closures, safe deposit box visits, and guarantee or power of attorney transactions, are written in the description 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 certain 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, branches, or types, the form section can be repeated for each cluster.

These three together demand something concrete from case management: a case must be able to carry non-monetary events, aggregate transactions within a date range to present them as a single line item, and generate separate clusters based on channel and branch.

How is the suspicion category selected?

When making a report, the suspicion is placed into one of the 38 categories in MASAK's reference table, and each category is matched with the relevant legal regulation. Usury and POS usury are linked to Article 241 of Law No. 5237, and encouraging or mediating prostitution is linked to Article 227. The list extends from tax evasion and fraudulent bankruptcy to illegal betting and the financing of the proliferation of weapons of mass destruction.

This means that case management must work with this taxonomy rather than its own free-form tags. Category selection is a part of the report itself.

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", governs the suspension of transactions based on a report. The guide sets a clear threshold for reports with a suspension request: rather than mere suspicion that the asset subject to the transaction is related to money laundering or terrorist financing, there must be supporting documents or serious indications supporting the suspicion, which must be sent along with the justifications.

This threshold directly generates a system requirement: the evidence must be attached to the case, the justification must be written, and who made the decision must be recorded. A note on the alert screen does not meet this threshold.

Where does the data reside?

Banks' information systems are subject to BDDK audit. This turns where the monitoring product runs and where customer data goes from a technical preference into an auditable matter.

TruvaLI supports on-premise deployment: the software runs on the bank's own infrastructure, customer data remains in the bank's information systems, and keys and the audit trail are under the bank's control. Cloud and private cloud also remain options; the decision belongs to the bank.

How does TruvaLI meet this?

Single customer view

Account and transaction data from core banking, ATM and spending records from the card system, collateral movements on the loan side, and records on the branch side are linked to the same customer record. Field mapping is dynamic, connecting without changing the bank's own data model; when a new field is introduced, it becomes available for rules. Transactions that remained at the attempt stage or were rejected are also stored, because T-001-3.14 also covers attempts.

Rule engine and relationship analysis

Types in the guide are converted into rules: with nested logic, flexible aggregation windows, and callbacks from rules. Linked account networks are mapped via shared addresses, phone numbers, devices, and IPs; relationship-based types like T-001-3.7 and T-001-3.16 are not left to single transaction checks.

Before deploying a new rule to production, you can test it on historical traffic in rule simulation to see the alert volume it will generate. You can also specify a past date and see the result on that day's traffic. 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 a total, and can generate separate clusters by channel. The suspicion category is selected from MASAK's 38-category taxonomy.

Information on who decided, with what authority, using which data, and when is written to the immutable audit trail; the second-pair-of-eyes approval runs via maker/checker. 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 bank.

The regulator of banks is BDDK; the counterparty for money laundering obligations is MASAK, and the framework is on the MASAK obligations page. Related flows: customer onboarding, ongoing monitoring, sanctions compliance, source of funds investigation, and regulatory reporting. The rule side is on the rule and scenario engine page, and deployment is on the on-premise deployment page.

Source

MASAK, "Suspicious Transaction Reporting Guide for Banks and PTT Limited to Banking Activities", MSK-RHB-ŞİB-001, 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 bank's own risk policy and obligations.