MASAK (Türkiye)
Let us be clear about the framing up front: Lunixi does not file reports with MASAK. The obligation — suspicious transaction reporting, continuous reporting, identity verification, record keeping and appointing a compliance officer — belongs to your institution. Lunixi provides the infrastructure you need in order to meet it: screening, evidence capture, records and audit trail.
Pending legal confirmation. The regulatory references on this page are derived from developer notes and configuration in the codebase. The interpretation of communiqué articles and the rationale for thresholds and periods have not been confirmed by legal counsel. Verify with your own compliance officer.
What we do and do not do
| Topic | Lunixi | Your institution |
|---|---|---|
| Fetching and maintaining the MASAK asset-freeze list | ✅ | — |
| Customer and transaction screening | ✅ | Setting policy and thresholds |
| Running the identity verification flow | ✅ | Approving the procedure |
| Capturing and retaining transaction purpose | ✅ | Defining the purpose list |
| Record keeping and audit trail | ✅ | Setting the retention policy |
| Assessing a suspicious transaction | Evidence and case file | ✅ The decision is yours |
| Filing a suspicious transaction report (STR) with MASAK | ❌ Not performed | ✅ Entirely yours |
| Appointing a compliance officer, corresponding with MASAK | — | ✅ |
MASAK asset-freeze list screening
Lunixi fetches MASAK's asset-freeze lists directly from source and feeds them into the screening engine.
| Source | The MASAK portal's live listing service (Ministry of Treasury and Finance) |
| Format | Live JSON — not a file download |
| Frequency | Daily morning synchronisation, Europe/Istanbul time |
| Fetch mode | Full list |
| Fields ingested | Name/surname/title, TCKN or tax number, nationality, sanction type, organisation, decision number, aliases |
Ingested records are versioned by digest (sha256); every synchronisation produces a run record with inserted / updated / unchanged counts, and the list is projected into the canonical screening schema.
List maintenance works in both directions:
- Delisting — records that disappear from the source are swept and the corresponding event is published
- Re-listing — a previously removed record that reappears at source is reactivated
There is also a dataset freshness watchdog: if the list is not refreshed within the expected window, that becomes visible. Screening silently against a stale list is a silent compliance failure, and it needs to be surfaced.
The MASAK list is not the only source screened. The platform also works with international sanctions lists, PEP data and adverse media screening. See Sanctions Screening.
Transaction purpose
In the wallet payment flow, a transaction purpose is mandatory: a payment request without a stated purpose is rejected with a validation error. The rule is not flag-gated — it cannot be turned off, it runs on every request, and it applies before limit reservation.
An honest boundary: this requirement is enforced on the wallet payment path. On the consumer-presented-mode (CPM) collection path and the merchant QR payment path, leaving the purpose field empty does not reject the request — a fixed default purpose for that flow is written instead. So "every wallet transaction carries a declared purpose" is not accurate; on QR and CPM collections the purpose may be a constant derived from the transaction type. Treat it that way in your own compliance assessment.
The captured purpose is retained as part of the transaction record and surfaces alongside the transaction at audit.
Türkiye identity verification rules
A dedicated ruleset is defined for Türkiye and the flow engine enforces it.
| Rule | Value |
|---|---|
| Regulatory frameworks | MASAK, KVKK |
| Accepted documents (Turkish nationals) | Turkish ID card, passport, driving licence |
| Accepted documents (non-Turkish nationals, remote) | Only an ICAO 9303 compliant passport with NFC — see Article 4/C |
| Liveness verification | Required |
| Alternative route for applicants declining biometrics | Required — an inclusion route must exist |
| Enhanced due diligence (EDD) threshold | Risk level HIGH (a risk level, not a monetary amount) |
| Number of documents | There is no jurisdiction-level cap; the flow you publish determines how many documents are requested |
| Documents required for KYB | Company registry document, tax certificate |
| Biometric image retention | 90 days |
| Identity verification record retention | 2920 days (8 years) |
Document expectations for the Turkish ID card
- Both sides required
- Eight visual security features checked: guilloche pattern, rainbow print, optically variable ink, latent image, hologram, micro-text, photograph and signature
- A defined minimum number of these must pass
- TCKN check-digit machine validation is performed
Non-Turkish national applicants — Article 4/C
Article 4/C, added to MASAK General Communiqué No. 19 by Communiqué No. 32 (Official Gazette 27/6/2026 – 33293), has been in force since 27 June 2026 and separately governs the remote identity verification of natural persons who are not Turkish nationals. The document list above applies to Turkish nationals; for a non-Turkish national the set of documents accepted remotely is narrower. This distinction arises from the regulation and cannot be relaxed by your flow configuration. Whether the platform can enforce the rule depends on the applicant's nationality being read reliably from the document; in an installation where document reading is not active, the rule produces no decision and only records the outcome. Please confirm with us which applies to your installation.
| Rule | What it means for remote identity verification |
|---|---|
| Accepted document | Only an ICAO 9303 compliant passport carrying a near-field communication (NFC) chip. An ID card, driving licence or residence permit is not accepted remotely for these applicants. |
| Chip verification | The passport chip is verified server-side (passive authentication: anchoring the signature chain to ICAO trust anchors). A result reported by the app is not accepted. |
| If verification cannot be completed | A business relationship cannot be established through remote identity verification. The application is not routed to manual review; it is terminated. |
| Nationals of countries you have determined to be risky | Cannot be accepted as customers through remote passport-based identity verification — even when chip verification completes without issue. |
| An accepted customer | Is classified as high risk and enhanced due diligence is applied. |
| Video verification | Video verification with these persons is conducted by specially trained personnel. |
Nationality is determined from the nationality field read from the document, not from what the applicant declares; the rule therefore applies once the document has been captured. If nationality cannot be read from the document, the application is not approved automatically — it goes to your team for review.
A refused applicant receives a reason that cites the article, in Turkish, rather than a raw error code; the same reason is shown in the operator panel.
You determine the risky-country list. The article leaves that list to the obliged party's own risk assessment, so the platform does not ship a country list on your behalf. Until a list is configured, no one is refused on this ground — while the article's other limbs (NFC passport only, no relationship where verification fails, high-risk classification) apply regardless of the list. Contact [email protected] to define yours.
The specially-trained-personnel requirement is yours to meet. The platform does not verify whether the operator conducting a video verification holds the special training the article requires. Identifying, training and keeping records for this personnel is part of your own compliance programme.
Quarterly statistical notification. The article imposes a quarterly statistical notification obligation for remote identity verifications in this scope. The platform writes every evaluation to the audit record: nationality country, document type used, the outcome of chip verification and how the application concluded. You file the notification through MASAK's own channels; the platform neither generates nor transmits the filing.
The required-document list for KYC is deliberately left empty in the ruleset — the merchant's flow configuration decides which documents are requested. The product does not impose a procedure on you; it executes yours.
Suspicious transaction reporting — stated plainly
The platform can mark a case as "to be reported to MASAK" on an analyst's decision. The mark is written to the case record and frozen into the encrypted decision snapshot.
A mark is not a report. There is today no code path in the codebase that generates, formats or transmits a suspicious transaction report to MASAK. There is no report form, no file generation, no interface to MASAK, no deadline counter. No subsystem even reads the flag.
You file the report through MASAK's own channels. Lunixi gives you the case, the evidence and the timestamped decision record; it does not perform the submission.
The structured suspicious-activity reporting engine that does exist in the platform is built for the United Kingdom and anchored to UK legislation (POCA 2002); it has no MASAK equivalent. Even there, submission is not automated — the compliance officer files on the authority's own portal and the system records only the reference and date as evidence.
We are not writing that this is "coming soon" either. Producing MASAK reports requires backend work first, and no promise will appear on this page before that work is done.
Records and audit trail
- Identity verification decisions, scores and timestamps are retained; the default retention for Türkiye is 2920 days
- The audit log is hash-chained — each row's digest derives from its own content and the previous row's digest, so record insertion is detectable
- Sanctions screening results are kept together with the identity of the list version they were screened against
For retention, erasure and data-subject requests, see KVKK.
Related pages
- FATF Guidelines — the global AML/CFT framework
- KVKK — personal data protection
- Sanctions Screening — the screening engine itself
For installation-specific screening coverage and compliance configuration, email [email protected].