Merchant risk and KYB in payment institutions

In payment institutions, the core of money laundering risk is the merchant, not the individual customer: the institution is responsible for the merchant's activity and the legitimacy of that activity. Institutions are obliged parties under Law No. 5549; their operational regulator is TCMB.

Who is the primary customer of a payment institution?

Payment and e-money institutions are obliged parties under Law No. 5549 on Prevention of Laundering Proceeds of Crime. MASAK publishes a joint suspicious transaction reporting guide for this group and expects reports to be submitted electronically via MASAK.Online.

Of the 76 types in the sector-specific section of the guide, 22 belong directly to the merchant. This ratio is no coincidence: a payment institution often sees the end user through the merchant, meaning money laundering risk primarily flows through the onboarded merchant.

Which indicators does the guide list?

How does the guide evaluate the merchant?

Some of the types look at the merchant's external appearance rather than its declarations.

None of these six can be addressed with documents in the merchant's file. The guide expects the website, pricing, and public records to be evaluated, regardless of what the merchant claims.

Is transaction volume proportional to commercial reality?

T-006-2.32 lists disproportion between the merchant's capital and purchase of goods or services and its collection amounts, T-006-2.29 lists suspicion that sales fall outside its commercial field of activity, and T-006-2.41 lists transactions of unusual count and volume compared to its sector.

When read together, these three measure whether the merchant's claims are consistent with its volume, rather than just what it claims. This comparison requires maintaining a reference distribution on a sector basis.

Post-onboarding

T-006-2.34 lists an unusual number of chargebacks for transactions at the merchant, T-006-2.37 lists transactions consisting largely of round amounts (such as 50, 100, 200), and T-006-2.33 lists transferring the accumulated balance in the merchant's account to third parties via internal transfers or assigning it through an assignment of receivables agreement.

T-006-2.38 and T-006-2.39 cover failure to provide requested information and documents in a timely and sufficient manner, provided documents being unrelated to the service offered, and inconsistencies between invoice numbers and transaction counts on invoices.

None of these can be detected at onboarding. They are all read from data generated after the merchant is onboarded. KYB begins with onboarding and continues with monitoring.

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 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 matched with the relevant legal regulation. The list ranges from usury and POS usury to tax evasion, fraud, and fraudulent bankruptcy.

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

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 this: rather than mere suspicion, there must be documents or serious indications supporting the suspicion that the asset subject to the transaction is related to money laundering or terrorist financing, and these must be sent 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?

Payment and e-money institutions are regulated and supervised by both TCMB and BDDK. This removes where the monitoring software runs and where customer data goes from being a mere technical preference.

TruvaLI supports on-premise deployment: the software runs on the institution's own infrastructure, customer and merchant 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?

Merchant onboarding

In the KYB workflow, the ownership structure is unwrapped to identify the ultimate beneficial owner (UBO), and authorized persons and corporate records are screened against sanctions, PEP, and internal lists. The onboarding decision and its justification are recorded.

External appearance of the merchant

T-006-2.28, T-006-2.35, and T-006-2.40 cannot be met through file checks. When a website address is provided, TruvaLI can scan the site end-to-end and extract its content, classifying adverse media and open-source records about the merchant by risk type. The same structure is used to create internal merchant lists.

Monitoring merchant behavior

Chargeback rates, round amount density, volume relative to sector averages, and balance movements feed into the rule engine. Thanks to nested logic and flexible aggregation windows, rules like "if the chargeback rate in the last 30 days rises to X times the sector average" can be built as a single rule, and tested on historical traffic via rule simulation before going live.

A network of relationships between merchants is extracted via shared IP, device, contact information, and balance transfers: transfer types to third parties like T-006-2.33 are not left to individual transaction checks.

Case, evidence, and category

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

Evidence and decision justifications are written to an immutable audit trail, dual-control approval is managed via maker/checker, and the documents and justifications required for reports with suspension requests are attached to the case. The draft report is prepared from the same case data, and signing remains with the institution.

The counterpart on the e-money side is on the e-money institutions page. Relevant workflows: merchant onboarding, ongoing monitoring, payment screening, chargeback and payment fraud, and regulatory reporting. The framework is on the MASAK obligations page.

Source

MASAK, "Suspicious Transaction Reporting Guide for Payment Institutions and Electronic Money Institutions", MSK-RHB-ŞİB-006, 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.