Fintech outstaffing compliance in 2026: GDPR, PCI-DSS, and Balkan data residency

The single most common reason a fintech delays placing engineering work in the Balkans is compliance uncertainty — most of which is easily resolvable once mapped against actual regulatory text rather than vendor anxiety. This piece is the compliance briefing we walk a CTO, CISO, or DPO through before signing the first engagement. It is structured around the four areas that actually require attention: data protection, payment card data, network and information security, and contractual posture.

1. GDPR: adequacy, SCCs, and what to do today

The Balkans is a mixed picture on GDPR adequacy. The position as of mid-2026:

| Country | EU adequacy decision | Practical implication | | --- | --- | --- | | Croatia | EU member state | No adequacy concern. Treat as domestic. | | Slovenia | EU member state | No adequacy concern. Treat as domestic. | | Bulgaria | EU member state | No adequacy concern. Treat as domestic. | | Romania | EU member state | No adequacy concern. Treat as domestic. | | Greece | EU member state | No adequacy concern. Treat as domestic. | | Serbia | Not on adequacy list | Standard Contractual Clauses + TIA required | | Bosnia & Herzegovina | Not on adequacy list | SCCs + TIA required | | Montenegro | Not on adequacy list | SCCs + TIA required | | North Macedonia | Not on adequacy list | SCCs + TIA required |

For the five EU member states, your data protection posture toward a Balkan-resident engineer is identical to your posture toward a Dublin- or Amsterdam-resident engineer. There is nothing material to do beyond your standard internal-employee data flow.

For the four non-EU jurisdictions — Serbia, Bosnia, Montenegro, and North Macedonia — the path is well-trodden:

• Standard Contractual Clauses. The 2021 SCCs (Module 2, controller-to-processor, or Module 3 if the partner is co-controller) are valid for transfers to all four jurisdictions.
• Transfer Impact Assessment. Required under Schrems II. The TIA documents your assessment of the destination country's legal regime, the nature of the data being transferred, and the safeguards in place. For Serbia in particular, the assessment is generally positive: the Serbian Personal Data Protection Act mirrors GDPR, the Serbian Commissioner is operationally independent, and government access to private-sector data is constrained by judicial process.
• Local data protection law. Each of the four jurisdictions has implemented GDPR-equivalent national law, with enforceable rights for data subjects and an independent supervisory authority. Your outstaffing partner should be able to produce evidence of its own data protection programme (DPO appointment, records of processing, breach response procedures).

In practice: budget half a day of DPO time per Balkan-resident hire to complete and file the TIA. After the first one, subsequent hires are repeat-pattern work.

2. PCI-DSS: keep engineers out of CDE scope

The most expensive mistake we see fintechs make is dragging Balkan-resident engineers into PCI-DSS Cardholder Data Environment scope unnecessarily. The right default posture is:

• Engineers do not have production CDE access. Period. Their work environment is staging, sandboxed processor data, or synthetic test cards. This is identical to how a Lisbon or Berlin engineer should be operating, and it is enforceable through your existing access control posture.
• Where production access is genuinely required (incident response, narrow on-call rotation), it is granted via the same break-glass procedure you operate for any other engineer: time-bound, logged, supervised, and reviewed.
• PCI-DSS does not require nationality or residency restrictions on engineer access. It requires controls — access management, logging, training, background checks. Those controls are provider-agnostic.

A reputable outstaffing partner will conduct background checks (criminal record, identity verification, professional reference) on every engineer before placement, and will be able to evidence this to your QSA. FinCircles produces a placement file on every engineer that meets PCI-DSS v4.0 §12.7 background-check expectations.

If your QSA tells you that engineering work cannot be performed from the Balkans, ask for the specific PCI-DSS requirement citation. There isn't one.

3. NIS2 and DORA

For UK fintechs operating into the EU, and for EU fintechs more broadly, two newer regulatory regimes intersect with outstaffing:

• NIS2. Applies to "essential" and "important" entities including most payment service providers. Imposes management-board accountability for cyber risk, including risk introduced by third parties. A Balkan outstaffing partner is a third party for NIS2 purposes — your partner due diligence file needs to cover their security posture (ISO 27001 status, incident response procedures, supply-chain practices).
• DORA. Applies to financial entities (including PSPs, EMIs, neobanks) from January 2025. Imposes specific contractual requirements on ICT third-party arrangements, including the engineering team you embed. The Register of ICT third-party arrangements must include your outstaffing partner. The contract must contain DORA Article 30 terms (audit rights, exit strategy, sub-contracting restrictions, security cooperation).

Both regimes are tractable but they require contract-level work up front. Sign with an outstaffing partner that has DORA-ready contract templates; signing with one that doesn't, and trying to retrofit, is materially more expensive than getting it right at engagement start.

4. The contract: what actually needs to be in it

The minimum contractual posture for a fintech engaging a Balkan outstaffing partner in 2026:

• Data Processing Agreement that names the SCCs Module by reference, identifies the data categories processed, and binds the partner to GDPR Article 28 processor obligations.
• DORA Article 30 terms if you are a financial entity: audit rights, sub-contracting consent, exit and transition support, security and operational resilience cooperation.
• PCI-DSS responsibility matrix if any engineer will have access (even logged, time-bound access) to systems within CDE scope.
• NIS2 third-party security clauses: incident notification, vulnerability disclosure cooperation, supply-chain transparency.
• IP assignment that vests all engineer-created IP in your entity. This is straightforward in EU member states; in Serbia and the other non-EU jurisdictions it is enforceable via the contract chain (engineer → partner → client), but the chain must be unbroken — verify your partner's engineer contracts include the assignment.
• Termination and replacement terms — you should be able to remove an engineer for cause within 7 days, and replace them on commercial terms that don't penalise you.

If your potential partner cannot produce these terms on first ask, the partner is not ready for a regulated-fintech engagement.

What this looks like in practice

A reasonable timeline for a UK EMI placing its first engineer with a Balkan partner:

| Week | Activity | | --- | --- | | 0 | Brief shared with partner; partner confirms scope and engagement model | | 1 | DPO completes TIA; legal reviews partner's DORA / DPA templates | | 2 | Contract executed; access provisioning begins for staging environment | | 3 | Engineer onboarded; first delivery commit; placement file filed in third-party register |

After the first engagement, the legal and compliance work is largely amortised. Subsequent engineers added under the same master agreement complete in 7–10 days.

The full operational picture sits in our Serbia hiring guide and the Croatia / Romania / Serbia comparison. For commercial structure, see engagement models.

A note on what compliance is not

Compliance is not a reason to avoid sourcing from the Balkans. It is a body of work — well-defined, repeatable, and substantively the same work you do for any cross-border arrangement. Fintechs that treat it that way are placing high-quality engineering in Belgrade, Zagreb, Sofia, and Bucharest with measurably lower friction than they place comparable engineering in San Francisco. Fintechs that treat it as a reason for deferral are paying twice — once in opportunity cost, once in the eventual catch-up.

If you would like a worked example for your specific regulatory posture — UK FCA, BaFin, Bank of Lithuania, Central Bank of Ireland — reach out. We will share the corresponding DPA, TIA, and DORA addendum that a comparable fintech has used to launch its Balkan engineering function.