Pay Contractors in Turkey on FAST and EFT With MASAK Controls

How FAST and EFT contractor payouts work in Turkey#

Use FAST for eligible TRY transfers that need round-the-clock processing, and EFT for amounts or routes outside your provider’s FAST support. First separate the commercial obligation from the payment service: who owes the contractor, who converts or holds funds, and which licensed institution executes the transfer? That map determines your controls and avoids treating a rail choice as a tax or employment decision.

1. Anchor on the few things that are actually well supported.

TCMB describes FAST as a separate instant TRY transfer system operating 24/7, with payments between accounts in seconds. Its published transfer limit is 100,000 TL; your institution may impose lower limits. FAST handles the domestic TRY leg. Funding from abroad, conversion and provider review can still extend end-to-end timing.

A practical checkpoint at this stage is simple. Confirm that your provider or banking partner can originate and track TRY payouts on FAST in test, and that your ledger can hold the original TRY amount without hidden FX reshaping. If you cannot prove that in a sandbox or pilot, you are not ready to promise fast contractor payouts.

1. Separate confirmed signals from unresolved compliance detail.

MASAK publishes duties for obliged entities, including customer identification and suspicious-transaction reporting. A business paying its own invoices and a payment institution intermediating client funds have different roles. Identify your role before implementing the licensed partner’s onboarding, monitoring and escalation requirements; using a partner does not automatically resolve your own regulatory scope.

EFT is a real-time gross-settlement system with working-day hours, rather than an always-open substitute for FAST. TCMB publishes weekday operation from 08:30 to 17:30, excluding public holidays, and until 13:00 on half days. Banks and providers can have earlier customer cutoffs. Use the contracted service’s schedule in your contractor-facing estimate.

1. Choose an entry posture that matches your tolerance for unknowns.

Proceed with a limited contractor payout cohort once the executing institution, supported account types, tax-document workflow and exception ownership are known. Delay live transfers if a required legal or provider eligibility condition is unresolved. If the work relationship requires employment, evaluate a lawful employment arrangement separately; EOR is an employment model, not a way to bypass payout compliance.

Version the rail limit and provider limits in configuration rather than embedding them in a permanent promise. For an approved 120,000 TRY obligation that exceeds FAST support, choose an eligible EFT route and communicate its schedule. Do not split the payment to evade limits or monitoring.

With that scope in mind, the next step is not engineering. It is getting the operating assumptions, owners, and documents into one place before anyone builds payout logic.

What to prepare before you commit engineering resources#

Before you write payout logic, lock scope, ownership, and evidence so open compliance questions are explicit instead of buried in implementation.

1. Define the payout scope.

Decide whether your first release covers only independent contractor payouts or mixed flows that may raise employee classification risk. State in one sentence which worker types are in scope and which are excluded from the pilot, and route mixed-scope plans to local legal review before build.

1. Assign legal and finance owners.

Name one legal owner for contractor status and documentation, and one finance owner for payroll compliance, withholding tax, and requirements that may depend on Turkish tax authorities. If those owners are not clear up front, engineering will encode assumptions that are expensive to unwind later.

1. Assemble the evidence pack.

Before build, prepare the operating documents: contractor agreement template, written classification rationale, payout approval matrix, and reconciliation export requirements for your planned TRY payout flow. Make reconciliation requirements explicit (required fields, payout reference format, approval timestamp, and exception sign-off).

1. Keep a known/unknown register.

Maintain a short decision register with the responsible institution, FAST/EFT support, current limits, tax-document owner and any unresolved eligibility condition. An unresolved condition that affects lawful release blocks live execution, including a pilot. A missing provider-specific return code can instead be resolved through an agreed manual recovery path before automation.

The non-negotiable compliance baseline in Türkiye#

Treat this baseline as release-critical even while Turkey-specific legal details are still being confirmed: if you cannot name the owner, required document, and release check for currency, tax, classification, misclassification escalation, and invoicing, you are not ready to send payouts.

1. Set TRY handling as a controlled design assumption.

Treat Turkish lira handling as a product and finance requirement from day one. Keep each payout traceable end to end: source currency, conversion timestamp, FX rate source, payout currency, and settled amount. If ops converts outside the platform, auditability and dispute resolution break quickly.

1. Document withholding logic and assign one update owner.

Choose withholding treatment from payer and contractor facts, including residency, legal form and the service supplied. Record gross fee, any required tax deduction, who remits it, and net amount due. Keep the rule version and supporting document with the payment; an invoice to an overseas customer does not by itself settle the contractor’s Turkish tax treatment.

1. Make contractor classification a real gate, not a label.

Do not treat "independent contractor" as just contract wording. Require written classification rationale, onboarding checks, and periodic review triggers based on your legal guidance, including where that guidance references Turkish Code of Obligations or Turkish labor laws. If legal has not produced that memo, launch is not ready.

1. Define a misclassification escalation path before payout release.

If the work relationship changes, review classification and the lawful employment or contractor arrangement promptly. Separate future onboarding/release restrictions from amounts already earned under the contract. A classification review does not itself justify an indefinite payment hold.

1. Include electronic invoicing readiness in release criteria.

GİB’s independent-profession guide describes electronic self-employment receipts (e-SMM) for non-exempt independent professionals. That is a different obligation from an e-Fatura registration threshold. Record the contractor’s tax status and expected document type, and link the issued receipt or invoice to the payment. Do not use a blanket 5-million-TRY transaction threshold for all contractor documents.

For a step-by-step walkthrough, see Gig Worker Tax Compliance at Scale: How Platforms Handle 1099s W-8s and DAC7 for 50000+ Contractors.

FAST and EFT selection for contractor payouts#

Choose FAST for supported inter-institution TRY transfers within the applicable amount and account limits. Use EFT when FAST is unavailable or the instruction is outside its supported limits, taking the provider cutoff and working-day calendar into account. In both cases, show provider submission separately from recipient receipt.

TCMB confirms the rail-level characteristics, but your bank or provider supplies the integration contract: account coverage, fees, customer cutoffs, status codes, references and return handling. Validate that contract with eligible low-volume payments after legal and onboarding prerequisites are satisfied.

Step 1. Match the rail to the promise you make contractors#

Start with your contractor-facing promise, not the rail label. If your product, support flows, or release conditions depend on fast payout confirmation, make FAST your primary route. If payouts are scheduled and your terms allow slower confirmation, EFT can remain a viable option.

Set one explicit checkpoint: the maximum acceptable time from payout release to contractor-visible confirmation in local time. If your team cannot state that clearly, rail selection is still guesswork.

Keep urgency, cutoff sensitivity, confirmed rejection and return handling separate. TCMB says completed transfers cannot simply be cancelled; an incorrect payment requires receiving-bank return handling through the sender’s bank. A timeout is not proof that the original transfer failed.

Step 2. Compare the rails on the criteria operators actually use#

Ask the provider which licensed institution executes the payment and how its references and final outcomes appear in your exports. A general employee-payroll guide is not evidence of contractor account eligibility.

Step 3. Define fallback routing before the first failed payout#

Document fallback routing before go-live. A "FAST first, EFT fallback" policy without strict states can create duplicate payouts.

Use at least these states: not sent, confirmed rejected before execution, unknown/pending, completed, and returned. Reroute only when non-execution is confirmed, or a completed transfer has been returned and the funds are available for replacement. A generic “failed” callback can describe a later stage and must not automatically trigger a second payment.

For manual review, capture the provider response, payout reference, attempt timestamp, contractor amount in TRY, and current ledger state. The goal is simple: avoid sending a second valid bank movement before you know the first one failed.

Test three paths before launch: FAST rejected, FAST pending, FAST successful. If your team cannot show deterministic next actions for each case, stay with the single rail you understand better operationally.

How to design the payout flow with compliance gates and traceability#

Design the flow so compliance can block a payout before funds move, and finance can reconstruct the full path after settlement.

1. Gate on a complete contractor file before approval.

Collect the agreement, engagement basis, tax-treatment decision, required receipt or invoice path and release approver. Resolve missing legal, contractual or provider prerequisites before the affected transfer. Review classification or tax uncertainty separately from amounts already earned, and document how existing obligations will be paid lawfully.

1. Keep approval narrow and auditable.

Record approver, payout amount in TRY, approval timestamp, and release reason. If payout follows currency conversion, also store source currency, conversion timestamp, and FX rate source so approved and settled amounts can be tied together.

1. Create one payout identity across retries and rail changes.

Link a single payout identity to payout reference, selected rail, provider response, and ledger entry. Avoid splitting status, operator notes, and reconciliation across separate systems.

1. Define exception handling before go-live.

Apply the same state policy across rails: confirmed non-execution permits a replacement; unknown/pending requires investigation; completed payments require return or recovery before a replacement. Keep each provider attempt under the same logical obligation, with its own reference and ledger effects.

1. Close only when reconciliation is complete.

Treat provider acceptance as an intermediate state, not the finish line. Finance should be able to match contractor file, approval record, payout reference, provider status history, and final ledger result without cross-team screenshot collection.

Related: How to Pay Contractors in Singapore: FAST PayNow and MAS Compliance for Platforms.

Choosing direct contractor payouts vs EOR or PEO#

Choose the engagement model from the actual work relationship. Direct contractor payouts suit independent service relationships. An EOR becomes the legal employer where its local arrangement is permitted; a PEO generally supports an employer’s administration and is not interchangeable with EOR. Neither model is a substitute for resolving an unauthorized payment activity.

Keep employee payroll documents separate from contractor tax receipts. A rail that can carry both kinds of payment does not make their tax, social-security or employment obligations identical.

For direct contractor payouts, verify the agreement, engagement basis, required tax-document path, approval and actual FAST or EFT reference. If a release prerequisite is missing, resolve it before the transfer; document how existing payment obligations will be met during any review.

Common failure modes and recovery actions#

The main failure risk is losing track of the payment or its release basis. Stop the next irreversible action, preserve the attempt and ledger records, and determine whether to correct data, investigate a pending transfer or seek return of a completed payment.

1. Failure mode: incomplete end-to-end evidence for a payout decision

Recovery: pause further release for that case until you can reconstruct the full decision path from approval through posting. If the record cannot be reconstructed cleanly, treat it as a control incident, not a routine exception.

1. Failure mode: missing, stale, or contradictory support documents

Recovery: resolve missing release-critical documents, assign an owner and explain the agreed remediation timeline. Apply a payout restriction only with a legal, contractual or provider-policy basis; document amounts already owed.

1. Failure mode: worker-status signals drift after onboarding

Recovery: review the changed work facts and document the lawful employment or service arrangement. Decide payment restrictions separately from classification and arrange settlement of already-earned obligations.

1. Failure mode: operations relying on guidance as if it were final legal direction

Recovery: treat current controls as operational safeguards only, and require counsel input for incident decisions that could change status, tax treatment, or reporting obligations.

Use a role-specific compliance runbook: the licensed institution handles its MASAK reporting and monitoring duties, while your team preserves the permitted transaction evidence and follows the agreed escalation path. Keep suspicious-report details restricted rather than including them in contractor notifications.

For the policy layer behind these controls, read How to Write a Payments and Compliance Policy for Your Gig Platform.

A practical 30-day Turkey launch sequence with go or no-go gates#

Use this 30-day sequence as a planning cadence, not a promise of regulatory clearance. Live pilot transfers begin only after required eligibility and lawful release conditions are satisfied; unresolved permission questions are not made safe by low volume.

1. Week 1: lock assumptions and unknowns

Write down legal, finance, and payout assumptions in one place, then separate confirmed points from open MASAK and EFT questions. Assign an owner and decision date to each open item so unknowns do not hide in informal threads. Gate: assumptions memo approved, with an exceptions register that clearly marks unresolved items.

1. Week 2: build the minimum defensible flow

Implement one end-to-end payout path with traceable records across onboarding, classification evidence, invoice trail, payout initiation, rail response, and TRY ledger posting. Keep the evidence chain attached to the case record so one payout can be reconstructed without manual stitching. Gate: one complete, auditable payout trail from approval to ledger.

1. Week 3: run controlled pilot payouts on the intended launch rail

Test low-volume payouts using the rail you actually plan to run at launch, and verify status visibility, retry controls, and reconciliation before increasing volume. Gate: one request maps to one final outcome and one matching ledger result, without duplicate-payment ambiguity.

1. Week 4: run a formal go/no-go review

Decide using evidence, not confidence: compliance file completeness, exception-handling readiness, and support/finance status consistency. Review pilot cases end to end before approving broader rollout. Gate: no unresolved issue that blocks lawful payout handling or clear payment-status explanation.

If a required permission, provider eligibility or legal release condition remains unresolved, stop live execution until it is resolved. If only automation is incomplete, use the approved manual process within its documented limits. Related reading: Pay Contractors in Mexico With SPEI for Platform Operators.

Conclusion#

Do not treat Turkey as a launch-now, clean-it-up-later market. The better call is to launch only when your team can separate confirmed operating rules from unresolved questions and put real owners on both.

MASAK’s obligations page covers obliged entities’ customer-identification, monitoring and reporting responsibilities. The useful launch test is whether each party’s role and required controls are implemented. A successful rail integration does not answer those questions by itself.

1. Confirm currency design. Lock down your intended currency path in product, ledger, and payout confirmations. For a test payment, ops and finance should both see the same currency result without manual explanation. Red flag: if conversion, release, and ledger posting can disagree, you are not ready.

2. Validate tax and contractor evidence. Make sure your tax logic, contractor documents, and invoicing responsibilities are assigned to named owners before first live volume. One contractor file should stand on its own with agreement, classification note, invoice path, approval, payout reference, and ledger match.

3. Choose a primary payout route and a fallback. Decide your first route, then define what happens when the first attempt fails or times out. The key failure mode is duplicate-payment exposure when a retry behaves like a new instruction instead of a replay.

4. Implement idempotent payout execution and a full audit trail. Every retry should resolve to the same payout identity, not create a second payable event. Your evidence pack should tie approval, operator action, provider status, and final ledger posting together.

5. Assign MASAK responsibilities. Identify the obliged institution, required onboarding data, transaction-monitoring ownership and reporting/escalation route. Keep confidential compliance decisions out of ordinary payee-facing status messages.

6. Run eligible pilot payouts and decide. Reconcile the approved payments end to end and test rejected, pending, completed and returned states. Expand only after eligibility, exception handling and support/finance status evidence agree.

If you can enforce those controls consistently, Turkey is a credible next market. If you cannot, the right move is not speed. It is a narrower scope, a different operating model, or a delay until the unknowns are genuinely controlled.