Data localisation in CIS payments: what cross-border online stores need to know

A shop based in the EU or Georgia that sells into Kazakhstan or Uzbekistan usually keeps its customer database where the rest of the business runs: one cloud region, one CRM, one data warehouse. Its payment providers keep their own copies. Then a partner, an auditor or a local acquirer asks a simple question: where is the personal data of your Kazakh customers stored? Few teams can answer it field by field.

This article explains which markets in the region have data localisation rules, what changed in 2026, what the rules mean for the checkout, the PSPs and the orchestration layer, and how card data under PCI DSS differs from personal data. It is not legal advice: it summarises published texts as of October 2026, and you should confirm how they apply to you with local counsel. For the payment side of these markets, see choosing payment providers for CIS and the Caucasus and our Kazakhstan guide.

Why does data localisation matter for a cross-border online store?

Because a payment touches more data than the card. A single order carries a name, an email, a phone number, a delivery address, an IP address and device data, often a saved card, and sometimes an identity check. Each of those sits with someone: the store, its PSPs, its fraud tools, its orchestration layer. A localisation rule asks where each copy lives.

That is why “where does each copy of the data live?” is a standard question from lawyers and security teams in the region, and why the answer differs country by country, as the sections below show.

What does Kazakhstan require?

Local storage, with transfers abroad allowed under conditions. Article 12 of the Law on Personal Data and their Protection, No. 94-V of 21 May 2013, says personal data is stored by the owner and/or operator, as well as by a third party, “in a database and/or digital storage facility located within the territory” of Kazakhstan. The official English text on Adilet shows Article 12 was last amended by Law No. 326-VIII of 24 June 2026.

The law’s definitions matter for a store:

• Owner: the person or company with the right of ownership, use and disposal of the database.
• Operator: the person or company that collects, processes and protects personal data.
• Storage: actions that ensure the integrity, confidentiality and availability of personal data.
• Processing: collection, storage, amendment, use, dissemination, anonymisation, blocking, destruction and erasure.

Article 16 allows cross-border transfer to countries that ensure the protection of personal data. Transfers to other countries are allowed with the data subject’s consent, under ratified international treaties, or in a few public-interest cases, and Kazakh laws may prohibit or restrict transfers.

The tension between Article 12 and Article 16 is where most questions sit. AmCham Kazakhstan’s issue brief of 15 May 2026 says the localisation clause “has survived multiple revisions”, and that Kazakhstan’s localisation rules do not provide for parallel storage, data synchronisation or primary and secondary databases. The same brief describes a draft decree that would lift mandatory storage for most categories of personal data and allow transfers to adequate countries or under binding corporate rules and standard contractual clauses. We could not confirm that the decree has been adopted, so plan on the current text.

What changed in Uzbekistan in 2026?

The rule was narrowed. According to Vakhidov & Partners, writing on Legal 500, all personal data of Uzbek citizens had to be stored in Uzbekistan before the reform. Law No. 1125 of 26 March 2026 limits mandatory local storage to three categories: biometric data, genetic data, and data of users of local telecom services.

Other personal data may be stored and processed abroad if one of three conditions is met: the country is recognised as adequate, the operator uses standard contractual clauses or binding corporate rules that meet the regulator’s requirements, or the operator complies with approved international standards. Kun.uz reports that the Cabinet of Ministers approved a list of 49 adequate countries and territories on 29 July 2026, including the US, the UK, Germany, France, Singapore and Russia. It also reports that a breach during a cross-border transfer must be reported within 24 hours, with a follow-up report within 72 hours, and that the President said the reform would open the way for Apple Pay and Google Pay.

For a store, the practical point is narrow but real: a selfie or other biometric check for an Uzbek customer still has to stay in Uzbekistan.

What about Kyrgyzstan, Armenia, Georgia and Azerbaijan?

They regulate transfers abroad rather than demanding local storage, as far as the sources we reviewed show.

• Kyrgyzstan. The Digital Code of 31 July 2025, No. 178, governs personal data. The National Investment Agency says transfers abroad are permitted subject to Kyrgyz law, for example with the data subject’s consent or under an international treaty. Its guide does not describe a storage requirement.
• Armenia. DLA Piper’s summary of Law HO-49-N of 18 May 2015 lists no localisation rule. Transfers are allowed with consent or to countries with adequate protection; transfers elsewhere under an agreement with safeguards need the regulator’s permission, decided within 30 days.
• Georgia. DLA Piper reports no general localisation rule under the law that took effect on 1 March 2024. Transfers need adequate safeguards, such as a country on the State Audit Office’s lists, a contract, or informed written consent. The data protection functions moved to the State Audit Office on 2 March 2026.
• Azerbaijan. We could not confirm the current position from an official source. Ask local counsel before relying on any summary.

How do the rules compare?

Market	Local storage required?	Transfers abroad	What to check
Kazakhstan	Yes, for personal data (Article 12)	Adequate countries, or consent and other listed grounds (Article 16)	Whether a local copy is kept; status of the draft decree
Uzbekistan	Only biometric, genetic and local telecom user data	Adequacy list of 49, contractual clauses or standards	Where identity checks and selfies are stored
Kyrgyzstan	Not stated in the guide we reviewed	Consent, treaty or other legal grounds	Consent wording at checkout
Armenia	No rule in DLA Piper’s summary	Consent or adequate country; permission otherwise	Contracts with non-adequate processors
Georgia	No general rule	Adequate safeguards, contract or consent	Representative if you process on servers in Georgia
Azerbaijan	Not confirmed	Not confirmed	Local legal review

What does this mean for the checkout, PSPs and the orchestration layer?

It means mapping roles and copies, not only servers. Under Kazakhstan’s definitions, the store that owns and controls its customer database is likely to be the owner. Each PSP, fraud tool and orchestration layer that collects, processes or protects that data on the store’s behalf is an operator or a third party, and Article 12 names all three. So the question goes to every party in the payment chain: which fields do you hold, in which country, and do you transfer them anywhere else?

Three points help:

• The checkout collects; the providers keep. With a hosted checkout, card details go straight to the provider or the orchestration layer, so the store’s own systems hold fewer fields.
• Each PSP has its own copy. A store with three providers in Kazakhstan has at least three places where a customer’s payment data is stored. Ask each one.
• Logs and exports count. A decline log, a reconciliation export or a support ticket that contains a name and a card number is personal data too.

Card data adds a second regime. The PCI Security Standards Council says PCI DSS applies to entities that store, process or transmit cardholder data. That standard sets how card data is protected; it does not answer where personal data must be stored. A card number linked to a named customer is also information about a person, so treat it under both regimes. Tokenization helps on both sides: the store keeps a token, and the card number stays in one PCI DSS compliant vault whose location you can ask about.

Worked example: mapping where each data field sits

Example figures, for illustration only.

An online fashion store based in Georgia sells to Kazakhstan and Uzbekistan. Its customer database runs in an EU cloud region. It lists the eight data fields its checkout and payments touch.

Field	Held by	Stored today	Kazakhstan customers	Uzbek customers
Name	Store	EU cloud	Local copy needed	Abroad allowed under conditions
Email	Store	EU cloud	Local copy needed	Abroad allowed under conditions
Phone number	Store	EU cloud	Local copy needed	Abroad allowed under conditions
Delivery address	Store	EU cloud	Local copy needed	Abroad allowed under conditions
Order history	Store	EU cloud	Local copy needed	Abroad allowed under conditions
Card number and expiry	Orchestration vault and PSPs	Ask each provider	Ask each provider	Ask each provider
IP address and device data	PSPs’ fraud screening	Ask each provider	Ask each provider	Ask each provider
Selfie for high-value orders	Identity check vendor	Vendor’s region	Local copy needed	Must stay in Uzbekistan

Five of the eight fields sit in the store’s own systems, two sit with the payment providers and the vault, and one sits with the identity check vendor: 5 + 2 + 1 = 8. The store’s own work is a Kazakh copy of five fields and a decision on the selfie check. The other three fields become questions in its provider contracts. Under the old Uzbek rule, all eight would have needed a local answer; after March 2026, only one does.

What are the common mistakes?

• Mapping servers instead of fields. A list of data centres does not show which customer data sits where. Start from the fields.
• Forgetting the providers’ copies. Every PSP, fraud tool and vault holds its own data. Each needs the same questions as your own database.
• Treating PCI DSS as the answer. A PCI DSS compliant vault protects card data; it does not settle where personal data must be stored.
• Relying on old summaries. Uzbekistan changed its rule in March 2026, Kazakhstan amended Article 12 in June 2026, and Georgia moved its regulator in March 2026.
• Ignoring identity checks. Biometric data is the category Uzbekistan still keeps at home.
• Skipping consent wording. Where consent is a transfer ground, the checkout text has to say what goes abroad and why.

How does Omno fit into a data localisation plan?

Omno does not decide where your customer data must live; that stays with you and your counsel. What Omno can do is reduce the number of copies: the hosted checkout captures card details, saved cards are tokenized and kept in a PCI DSS compliant environment rather than in your systems, and routing-decision logs and data export show which provider handled each payment. Ask Omno, as you would any provider, where the data it holds is stored. The tokenization and saved cards page covers the vault.