Operating a crypto exchange (a platform enabling users to buy, sell or convert digital assets against fiat or other crypto) without proper regulatory authorisation in Kazakhstan's Astana International Financial Centre (AIFC) exposes the business to enforcement action, payment-rail suspension and permanent loss of banking relationships. The AIFC's common-law environment, administered by the Astana Financial Services Authority (AFSA), offers a credible, internationally recognised licensing path for inbound operators – but only if the structure, the licence scope and the cross-border obligations are resolved before the application is filed. This page maps the regulated basis, the inbound process, the banking and tax interaction, and the decision points a general counsel or founder must work through before committing capital to the AIFC.
What is the regulated basis for running a crypto exchange in the AIFC?
An operator wishing to run a digital-asset trading facility (an exchange matching buyers and sellers of virtual assets) inside the AIFC must obtain a licence from AFSA before conducting regulated activities. The AIFC operates under a common-law legal regime, distinct from Kazakhstan's civil-law system, and AFSA administers the applicable digital-asset rules independently of national Kazakhstani financial regulation. That separation is material: an entity regulated by AFSA operates under AIFC rules, not under the broader Kazakhstani VASP supervision framework that applies outside the AIFC perimeter. The distinction between the two regimes – AIFC and non-AIFC – is the first structural question every inbound operator must answer.
Under the AFSA framework, digital-asset activities are carved into regulated categories. Running a trading platform falls squarely within the licence perimeter. Custody of client assets, advisory services and the provision of digital-asset transfer or settlement services each attract separate authorisation requirements. An operator building a full-service exchange – matching engine, custody of client funds, and fiat on/off-ramp – will typically need to address more than one regulated activity in the licence application. Treating the authorisation as a single-activity licence and then expanding operationally is a common and costly structural error. We address that further in the process section below.
The AIFC's regulatory perimeter matters for marketing and user jurisdiction. A licence issued by AFSA authorises activity inside the AIFC zone. Serving users in mainland Kazakhstan, in EU member states (where MiCA applies), or in jurisdictions with their own VASP registration requirements triggers separate obligations in each of those markets. A single AIFC authorisation does not passport into any of those regimes automatically.
To scope your licence application and map the cross-border overlay, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity structure, the user base, the banking relationships – change the analysis materially.
What licence categories apply to a crypto exchange under AFSA?
AFSA's digital-asset regime recognises a range of regulated activities, and the correct licence category is determined by the substance of the business, not by the label the operator chooses to apply. For an exchange, the primary regulated activity is operating a digital asset trading facility – a regulated marketplace where buyers and sellers transact in digital assets, including order-book matching, over-the-counter desks and automated market-making infrastructure.
Where the exchange also holds client funds – whether in fiat pending settlement or in digital assets between transactions – the custody dimension becomes a separate regulated activity. AFSA treats providing custody services for digital assets as a distinct licence category. An exchange that commingles the two without the appropriate multi-activity authorisation is operating partially outside its licence scope from day one. That is not a technical deficiency that can be remedied quietly: it is a material breach of the authorisation conditions.
Fiat integration introduces a third layer. If the business operates a fiat-to-digital-asset gateway, the relevant money-services dimensions of that activity need to be evaluated against AFSA's requirements and, critically, against the requirements of the banking partner processing the fiat leg. In our practice, the banking underwriting of the fiat gateway is frequently the longest lead-time element in an AIFC exchange build – longer than the licence process itself.
Advisory services, staking-as-a-service, and lending or margin-trading facilities each attract their own analysis. An operator launching with a minimal feature set and planning to expand should map the full intended product roadmap against the licence categories before the initial application. Adding regulated activities post-authorisation requires a formal variation – a process that takes additional time and resurfaces the full underwriting scrutiny.
How does the inbound application process work for a foreign operator?
The AIFC application process for a foreign operator follows a structured sequence: corporate establishment inside the AIFC, preparation of the regulatory business plan, submission to AFSA, in-principle approval, and final authorisation. Each stage requires substantive preparation; AFSA's review is document-intensive and expects a credible, board-approved operating model rather than a placeholder plan.
The first structural decision is the AIFC entity. Most inbound operators establish either a private company or a limited liability partnership under AIFC company law. The entity must be genuinely based in the AIFC – a registered address and a nominal director will not satisfy AFSA's substance expectations. The authority expects key management functions, including compliance oversight, to be demonstrably present in the AIFC or accessible to it.
The regulatory business plan is the centrepiece of the application. It must address the business model, the governance structure, the AML/CFT programme (aligned to FATF Recommendation 15 on virtual assets and the applicable Travel Rule – the obligation to pass originator and beneficiary data with a transfer), the technology architecture, and the financial projections. AFSA reviewers interrogate each element. Incomplete or inconsistent plans are returned, resetting the clock. In our experience, applications with well-structured AML frameworks and credible technology assessments progress more predictably than those that treat compliance as an afterthought.
Timeline is jurisdiction-specific and AFSA does not publish a fixed processing period. It varies by application complexity, the applicant's prior regulatory history and the completeness of the submission. Applications for a single regulated activity with a well-prepared file move faster than multi-activity applications or those involving novel product structures. Operators should plan for a process measured in months, not weeks, and build that runway into their capital planning.
In a recent licensing matter, a payments company entering the AIFC sought to launch an exchange alongside a custody facility and a fiat gateway under a single application. We restructured the application into a primary exchange licence with a concurrent variation request for custody, staged the fiat gateway as a post-authorisation expansion, and aligned the AML programme to AFSA's documented expectations before submission. The application progressed without a request for information, and the client achieved regulatory readiness ahead of its commercial launch window.
How do AML and the Travel Rule apply to an AIFC exchange?
An AIFC-licensed exchange operates under AML/CFT obligations that track the FATF standards, including the Travel Rule requirement to transmit originator and beneficiary data alongside virtual asset transfers above the applicable threshold. AFSA expects a documented Travel Rule policy and a technology solution capable of transmitting, receiving and screening that data at scale before the exchange goes live.
Travel Rule compliance is not simply a data-transmission exercise. It requires counterparty VASP due diligence – an operator cannot transmit Travel Rule data to an unknown or non-compliant recipient and call the obligation met. The exchange must maintain an updated record of the VASPs with whom it transacts and apply a risk-based assessment to those relationships. AFSA will examine the programme during authorisation review and in subsequent supervision cycles.
The cross-border complexity of Travel Rule compliance is acute for an AIFC exchange with a global user base. A transfer to or from a user at a VASP in a MiCA-regulated EU jurisdiction, a Singapore MAS-licensed institution or an FCA-registered firm in the UK must satisfy the receiving regime's Travel Rule standard as well as AFSA's. Those standards are not identical. Calibrating the programme to the most demanding applicable standard across counterparty jurisdictions is the only sustainable approach.
KYC and customer due diligence obligations follow the same FATF baseline. For an exchange serving institutional and high-volume retail clients, enhanced due diligence and source-of-funds verification at onboarding are standard expectations. Regulators in the leading hubs increasingly expect transaction monitoring to be automated and calibrated to the specific risk profile of the platform – a peer-to-peer crypto exchange has a materially different risk profile than a corporate treasury desk, and the monitoring parameters should reflect that.
What is the banking and tax interaction for an AIFC exchange?
Banking for a crypto exchange operating from the AIFC is the most operationally critical and least predictable element of the build. The AIFC's common-law framework and AFSA's credible regulatory standards help with correspondent banking conversations, but they do not guarantee an account. In our cross-border practice, we have seen well-structured, fully licensed operators spend more time securing stable banking rails than they spent on the licence itself.
The practical approach is to treat the banking relationship as a parallel workstream, not a post-licence task. Most banking partners conducting VASP due diligence want to see the regulatory application in progress, the AML framework documentation, the ownership structure and the operational geography of the user base. Starting that conversation after authorisation is obtained wastes time that can be used productively in the pre-licence period.
Fiat settlement for an AIFC exchange may route through Kazakhstani banks, through international correspondent relationships, or through fintech infrastructure. Each route carries its own compliance overhead and its own geographic limitations on currency corridors. An exchange expecting to serve users across multiple currency zones needs a banking architecture that can support that from launch, not a single-account arrangement that collapses under volume or geographic expansion.
On the tax side, the AIFC offers a distinct tax environment under Kazakhstani law, with specific exemptions available to AIFC-registered entities on certain income streams. The interaction between those exemptions, the corporate tax position of the parent entity (if the AIFC entity sits inside a group), and the withholding tax profile on cross-border payments requires analysis before the structure is finalised. The headline tax treatment of an AIFC entity is materially different from the tax position of a company operating in mainland Kazakhstan, but the conditions for qualifying treatment must be met by substance and operation, not simply by registration.
If the banking or tax architecture for your AIFC exchange build has stalled, write to OBOLUS at info@oboluslaw.com. If a prior application stalled or an account was closed, a second structural read can surface the reason and the route forward.
Does an AIFC licence cover operations in other jurisdictions?
An AIFC authorisation does not automatically confer the right to serve users or conduct regulated activities in other jurisdictions – that is the most persistent misunderstanding we encounter in inbound licensing work. An operator licensed by AFSA is authorised to conduct the relevant activities within the AIFC regulatory perimeter. Serving users domiciled in the EU triggers MiCA CASP authorisation requirements. Serving users in Singapore triggers MAS Payment Services Act obligations. Serving UK users triggers FCA financial promotion and MLR registration requirements. None of those obligations are satisfied by the AIFC licence alone.
The cross-border question also runs in the other direction. An AIFC exchange with a parent entity in a third jurisdiction, or with investors in regulated markets, needs to map the licensing obligations that those relationships create in those jurisdictions. A fund investor subject to US regulatory requirements may impose contractual licensing conditions. A majority owner regulated by the FCA may trigger FCA group supervision. The AIFC licence is the operating layer for the Kazakhstan-AIFC entity; it does not resolve the regulatory map for the group.
For operators who do genuinely need to serve a multi-jurisdictional user base, the strategic question is whether the AIFC is the primary licensing hub with allied registrations in secondary markets, or whether a different hub – MiCA-passportable, or Singapore-anchored – is more efficient given the user geography. That decision turns on the operator's user base, product type, banking geography and growth horizon. We map those decision axes before any application is filed.
Which operator profile fits the AIFC exchange route?
The AIFC suits a well-defined set of operator profiles, and it is not the right primary hub for every digital-asset business. Understanding where it fits saves the cost of a misdirected application.
Profile A – the Central-Asia-first operator. A business building primarily for users in Kazakhstan and the Central Asian region, with institutional clients and a structured governance model, finds the AIFC's common-law environment and AFSA's credibility with regional banking partners directly useful. The licence covers the core market, the legal system is familiar to international counsel, and the AIFC courts provide a dispute-resolution forum that regional banking and institutional counterparties accept. Timeline: subject to application complexity; plan for a process measured in several months.
Profile B – the diversified-hub operator. A business with an existing EU, Singapore or UK regulatory relationship looking to add an AIFC presence for access to regional markets or for structural diversification finds the AIFC licence workable as a secondary regulated entity. The cross-border interaction between the primary regulator and AFSA needs to be mapped, particularly at the group-level AML and governance layers. Timeline: similar to Profile A; the added complexity is group-level regulatory coordination.
Profile C – the global-scale exchange. A business intending to serve a broadly global retail user base across multiple currency zones needs more than an AIFC licence. The multi-jurisdictional registration burden – MiCA, MAS, FCA, and potentially US state money-transmitter licences – means the AIFC is one element of a multi-hub stack, not a standalone solution. For this profile, the AIFC may still be the right operational entity for the Central Asian segment, but it must be planned as part of a coordinated multi-jurisdiction build from the outset.
Profile D – the lean startup without substance. An operator seeking a low-cost, low-substance offshore presence will find AFSA's substance expectations an obstacle. The AIFC's regulatory credibility derives partly from the fact that it enforces those expectations. Operators who do not intend to place real management, compliance capacity and operational infrastructure in the AIFC should consider whether the regulatory fit is there before initiating an application process.
Related at OBOLUS
- Licensing & Registration for Digital-Asset Businesses – our full practice overview across 70+ jurisdictions and all major licence categories
- EMI Licence for Crypto Firms – Cross-Border Perspective – how an e-money institution licence interacts with a VASP or exchange authorisation across multiple regimes
- Crypto Fraud and Asset Recovery – Cross-Jurisdiction Comparison – the dispute and recovery options available when exchange assets are misappropriated
What are the most common mistakes in an AIFC exchange application?
The mistakes we see most frequently in AIFC exchange applications share a common origin: the business plan is built around the commercial model, and the legal structure is assembled around it after the fact. By the time the application is drafted, the structural problems are embedded and expensive to fix.
The first error is scope mismatch – applying for a single regulated activity while operating a multi-activity business from day one. An exchange that holds client assets is operating a custody function, and an unlicensed custody function is a compliance breach from the moment the first client deposit arrives. Mapping the full activity scope before applying, not after, is not a counsel preference – it is a requirement of a credible application.
The second error is AML-programme staging. Some operators treat the AML framework as a document to be finalised after authorisation, on the assumption that the regulator will approve a framework in principle and allow the details to follow. AFSA's experience with that approach is limited; the authority expects a complete, board-approved AML programme at the time of submission. A skeleton programme delays the application and signals organisational immaturity.
The third error is the banking afterthought. As noted above, banking for a crypto exchange is a parallel workstream. Operators who treat it as a post-licence task frequently discover that the banking partner they assumed would accept them has changed policy, tightened its VASP onboarding criteria, or requires documentation that the exchange cannot yet produce. The result is a licensed entity without functional banking rails – commercially inert and burning runway.
A common assumption among operators exploring the AIFC is that any offshore regulatory licence is broadly equivalent and that the choice of jurisdiction is mainly a cost and speed optimisation. That is not correct. AFSA's regime is substantive. The examination of governance, technology, AML and capital adequacy is real. An operator that enters the process expecting a light-touch registration and encounters a full regulatory authorisation review will face either a lengthy remediation process or a rejected application. We map the realistic expectations before any engagement begins.
FAQ
How long does a crypto licence take to obtain?
Timeline varies by jurisdiction, licence category and application quality. Under the AFSA regime in the AIFC, a well-prepared single-activity application progresses over a period of several months from submission to final authorisation. Multi-activity applications, novel product structures or submissions with incomplete compliance documentation take longer. AFSA does not publish a fixed statutory processing period. Operators should build a realistic runway – measured in months, not weeks – into their capital and commercial planning before filing.
Which jurisdiction is best for licensing my crypto business?
There is no universally optimal jurisdiction. The right hub depends on the operator's user geography, product type, banking relationships and growth horizon. The AIFC suits operators with a Central Asian or regional focus, or those building a diversified multi-hub structure. Operators targeting EU retail users need a MiCA CASP authorisation; Singapore-anchored businesses need MAS Payment Services Act licensing. We map the full decision matrix – licence, banking and tax – before recommending a structure, because the interaction between those layers often determines the practical answer.
Do I need a separate custody licence?
In most substantive VASP regimes – including AFSA in the AIFC – custody of client digital assets is a distinct regulated activity, separate from operating a trading facility. An exchange that holds client assets between transactions is providing custody, whether or not it describes itself that way. A licence that covers only the trading-facility activity does not authorise the custody function. Operators building a full-service exchange should address the custody authorisation in the initial application rather than treating it as a subsequent variation, which restarts the regulatory review process.
OBOLUS is an independent digital-asset law boutique acting exclusively for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions – including the AIFC, MiCA, MAS and FCA regimes – on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance structures that sit around them. We map the licence, banking and tax stack across operating, custody and payment layers before you commit capital to a structure. We work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications where recovery is needed. Digital assets are the whole of our practice. To discuss your AIFC exchange build or any related multi-jurisdiction matter, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Aisha Tan, Licensing & Jurisdictions Analyst – specialising in inbound regulatory authorisation for digital-asset exchanges and custodians across the AIFC, MiCA, MAS and allied VASP regimes.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.