A digital-asset exchange building fiat on/off-ramp capability in Kazakhstan's AIFC discovers quickly that the banking question is also a licensing question, a compliance question and a cross-border structural question – all at once. Fiat on/off-ramp banking (the infrastructure that converts customer fiat deposits into digital assets and routes proceeds back to bank accounts) sits at the intersection of the Astana Financial Services Authority (AFSA) regime and the domestic banking sector, and neither side moves without the other. This page sets out the regulated basis, the practical path for an inbound operator and the decision points that determine whether a Kazakhstan-domiciled structure can carry your payment rails without stranding your business.
The AFSA Regime and Why Fiat Rails Are Regulated
Fiat on/off-ramp activity in the AIFC is regulated from the first customer transaction, not from a revenue threshold. The Astana International Financial Centre (AIFC) operates as a common-law jurisdiction within Kazakhstan, with the AFSA as its financial-services supervisor. Digital-asset trading facility and custody operators working within the AIFC must hold the relevant authorisation before accepting fiat from clients. An entity that moves fiat without that authorisation – even as an operational convenience – is exposed to regulatory sanction and, critically, to immediate banking termination.
The AFSA regime treats the conversion of fiat to digital assets, and back again, as a financial-services activity. That means the AFSA oversees it as a regulated function sitting alongside, and interacting with, the digital-asset trading and custody categories. Operators we advise frequently underestimate this point. They assume a technology platform that connects third-party payment processors to a digital-asset facility avoids the regulated perimeter. In our practice, regulators in the leading hubs – including the AFSA – apply substance-over-form analysis: if the economic function is fiat conversion, the regulatory trigger follows.
The AIFC's common-law base matters practically. Contract law, dispute resolution and corporate structuring within the AIFC run on English-law principles. That provides a governance baseline that international banking partners – particularly those headquartered in London, Singapore or Dubai – recognise and can underwrite. It is one of the reasons operators in the Central Asian market increasingly choose the AIFC as the licensed entity rather than a less structured onshore alternative.
For a scoped assessment of your fiat rails structure in the AIFC, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity type, the user base geography, and the banking relationship – change the analysis materially. Map your options
Who Needs an AIFC Authorisation for On/Off-Ramp Activity?
Any operator accepting fiat currency from clients in exchange for digital assets – or remitting fiat proceeds to clients after a digital-asset sale – and doing so through an AIFC-registered entity requires the appropriate AFSA authorisation for that activity. This covers exchanges, OTC desks, payment intermediaries structuring fiat sweeps, and custody operators that facilitate fiat settlement for institutional clients.
The cross-border dimension is significant. An entity incorporated outside the AIFC that directs fiat flow through an AIFC-registered vehicle – even as a subsidiary treasury function – brings that vehicle into the regulated perimeter. Regulators in the leading hubs increasingly expect the entity holding the payment relationship to be the entity holding the licence. Structural mismatches between where the contract sits and where the licence sits are among the most common issues we encounter in inbound mandates.
The relevant question for an operator assessing whether AFSA authorisation is required is functional, not formal. Does the entity accept, hold or transmit fiat in the course of providing digital-asset services? If yes, the authorisation requirement applies. A common mistake is to route fiat through a domestic Kazakhstani bank in the entity's own name, on the assumption that this is treasury management rather than a regulated payment service. The AFSA's activity-based approach will test the substance of that arrangement.
Why Do Fiat Rails Break for Crypto Businesses in the AIFC?
Fiat rails break for crypto businesses in the AIFC for the same structural reasons they break everywhere: banks apply de-risking policies that treat digital-asset businesses as elevated compliance risk, and the AIFC-specific solution is to demonstrate regulatory standing that satisfies a bank's own risk appetite. Without a live AFSA authorisation, a demonstrable compliance programme and a clear explanation of the client-money flow, domestic and international banking partners will decline or terminate the account.
In our cross-border practice, the failure point is almost always documentary. A bank's compliance team wants to see the licence, the AML/KYC policy, the transaction-monitoring architecture and the ownership structure – all in a form the bank's legal team can approve. An AIFC operator that cannot produce this package within the bank's initial-screening window is deprioritised, regardless of the commercial relationship on offer.
The AFSA regime creates a defined compliance baseline that a well-prepared operator can present to banking partners. That baseline includes adherence to FATF Recommendation 15 on virtual assets and – where applicable – the Travel Rule (the obligation to pass originator and beneficiary data with a transfer). Banks in the region, and their correspondent banking partners internationally, treat Travel Rule compliance as a threshold question. An operator that cannot demonstrate a working Travel Rule solution before opening discussions with a bank is unlikely to progress past the first screening call.
What Is the Process and Timeline for AFSA Authorisation?
The AFSA authorisation process for an entity seeking to carry on regulated digital-asset activities – including those that support fiat on/off-ramp services – follows a structured application track. The AIFC's common-law framework means the procedural steps are documented and, in our experience, predictably administered. Timeline is a function of application quality, not an unknowable variable.
The application requires, at a minimum: a business plan setting out the regulated activities, the target market and the operational model; an AML/CFT policy and procedure manual; a compliance and governance structure including the appointment of a compliance officer acceptable to AFSA; a financial crime risk assessment; and evidence of the capital base required for the licence category sought. Capital and fee levels are set by the AFSA and vary by activity type; we advise clients to confirm current requirements directly with the regulator during pre-application engagement, which AFSA actively facilitates.
Pre-application engagement is not optional in practice. The AFSA offers – and expects – a pre-application meeting at which the proposed structure is reviewed before formal submission. Operators who skip this step and submit cold applications invariably receive a request for further information that extends the overall timeline. In our practice, a well-prepared applicant who has used the pre-application process and submitted a complete file can expect the review to move at a pace consistent with the AFSA's published service standards – typically a matter of weeks to a few months depending on the complexity of the application and the regulatory category.
Banking onboarding runs in parallel with, not after, the authorisation process. The most efficient operators approach their target banking partners with a draft compliance package before the licence is granted and then provide the executed authorisation as a condition precedent to account activation. Waiting until licence receipt to begin banking discussions costs weeks or months that the business cannot afford.
If a prior application stalled or a banking relationship was closed, OBOLUS can surface the structural reason and map the route back. Write to info@oboluslaw.com. Map your options
How Does AIFC Structuring Interact with Cross-Border Tax and Banking?
An AIFC entity holding digital-asset and payment authorisations is a Kazakhstan-domiciled legal person for most tax treaty purposes, yet it operates in a common-law environment that international counterparties treat as functionally equivalent to a DIFC or Singapore entity. That dual character is the AIFC's competitive positioning – and it creates specific structuring considerations that operators must resolve before they commit capital.
The tax interaction is the first decision point. Kazakhstan has a treaty network, and the AIFC offers specific tax incentives to entities operating within the zone. Whether those incentives apply to a given payment or digital-asset activity, and how they interact with the residence of the entity's beneficial owners and the jurisdiction in which customers are located, requires a jurisdiction-specific analysis. We work through this with clients as part of the initial structure review, rather than treating tax and licensing as separate workstreams.
The banking interaction is the second decision point. Domestic Kazakhstani banks serve the local fiat corridor, but most international payment flows require a correspondent banking relationship. That means the AIFC operator's banking stack typically includes a domestic account for local fiat settlement and an international account – often held at an EMI (electronic money institution) registered in the EU, the UK or another major financial centre – for cross-border rails. The choice of EMI partner determines which currency corridors are available, what the settlement speed is, and what the compliance burden looks like for the operator's users.
The AIFC's common-law base and AFSA authorisation make the entity legible to European and UK EMIs in a way that a purely onshore Kazakhstani entity often is not. In our practice, operators who have structured the AIFC holding company correctly and hold a live AFSA authorisation find EMI onboarding materially more tractable than operators approaching EMIs from an offshore shell structure. The EMI's compliance team can underwrite a regulated entity within a known legal regime; it cannot easily underwrite an unregulated entity regardless of its commercial standing.
EMI Onboarding and Client-Money Safeguarding
Securing an EMI relationship for an AIFC digital-asset operator requires the same documentary foundation as the AFSA authorisation process, presented in the EMI's own compliance format. The EMI is itself a regulated entity – typically under the EU's Payment Services Directive, the UK's Payment Services Regulations, or an equivalent regime – and its compliance team applies its own risk-appetite policies to every business client. An AIFC operator presenting an AFSA authorisation, a clean AML/KYC framework and a structured client-money explanation will clear that process materially faster than one presenting without it.
Client-money safeguarding is the point most operators handle inadequately. Client-money safeguarding refers to the legal and operational requirement to hold client fiat balances segregated from the operator's own funds, in a manner that protects those balances in an insolvency scenario. Most flagship regimes – including those applicable to EMIs and to digital-asset operators holding client fiat – impose safeguarding obligations that are both a licensing condition and an ongoing operational standard.
For an AIFC operator, the safeguarding question has two layers. First: does the AFSA authorisation require the operator to hold client fiat in a segregated account, and with what institution? Second: does the EMI relationship itself impose safeguarding obligations on the pass-through of client fiat before it is converted into digital assets? The answers to both questions must be reflected in the operator's operational procedures, its client agreements and its disclosures. Operators we advise routinely discover that their draft client agreements do not accurately describe the safeguarding arrangement – a gap that creates both regulatory and civil liability.
In a recent matter, a payments business operating across two Central Asian jurisdictions sought to onboard with a European EMI while holding a legacy registration that predated the applicable AML reforms. We reviewed the existing compliance architecture, identified the gaps against the EMI's stated requirements and the relevant regulatory baseline, restructured the client-money flow documentation and prepared the EMI onboarding package. The client received account activation within the EMI's standard processing window. The structural issue that had blocked the prior attempt was a mismatch between the entity holding the client contract and the entity named in the compliance manual – a common and correctable problem.
Which Operator Profile Benefits Most from an AIFC Structure?
Not every operator should anchor its payment infrastructure in the AIFC. The structure suits specific profiles, and being clear about which profile applies to your business is the starting point for an honest structuring conversation.
A Central Asian-facing exchange or OTC desk – one whose primary user base is in Kazakhstan, Uzbekistan or the surrounding region – is the clearest fit. The AIFC provides a credible regulated home, a common-law legal environment and proximity to the relevant market. Banking relationships with domestic institutions are straightforward to establish once AFSA authorisation is in place. The cross-border risk is manageable: the operator needs an EMI for international currency corridors but can anchor domestic fiat settlement through Kazakhstani banking partners.
A global exchange using the AIFC as a regional hub – maintaining primary licensing in Singapore, the EU or the UAE while holding an AIFC authorisation for Central Asian operations – benefits from the AIFC's common-law base and its recognition among international banking partners, without being dependent on it for the totality of its compliance stack. The key structuring discipline is ensuring that the AIFC entity does not inadvertently assume regulatory obligations that belong to the primary licensed entity, particularly on client-money flow and AML-programme ownership.
A payments-led business or EMI seeking to access the Kazakh fiat corridor without a full digital-asset trading licence sits in a different position. The applicable regulatory track within the AIFC differs from that of a trading facility operator, and the banking approach differs accordingly. The decision axis here is whether the entity is primarily a payment service provider that touches digital assets, or a digital-asset operator that touches payments – the regulatory and banking treatment diverges at that point.
An operator that is predominantly serving clients in the EU, UK or US, with no material Central Asian user base, will typically find that an AIFC structure adds a compliance layer without materially improving its banking access in those primary markets. In that scenario, licensing in Lithuania under the Bank of Lithuania and the MiCA CASP track, or a MAS-regulated Payment Services Act structure in Singapore, is likely a better primary anchor.
A Common Assumption That Costs Operators Time and Money
A common assumption among operators entering the AIFC is that a single offshore licence – a BVI or Cayman registration, or a legacy Eastern European VASP registration – is sufficient to serve clients globally, including through AIFC-facing payment rails. It is not. The AFSA's activity-based approach means that an entity offering services to clients through the AIFC structure must hold the AFSA authorisation for those activities, regardless of what licences are held elsewhere. The offshore licence addresses the entity's own jurisdiction; it does not satisfy the AFSA's requirements for regulated activity conducted within or through the AIFC.
The practical consequence is enforcement exposure and banking risk. A bank onboarding an AIFC entity will check the AFSA register. An entity not appearing on that register as an authorised person will not pass the bank's due-diligence screen, regardless of its offshore licensing status. We have seen operators spend months negotiating banking terms, only to have the account application declined at the final compliance-review stage because the AIFC entity lacked its own AFSA authorisation. The cost of that delay – in management time, in opportunity cost and in the need to restructure – exceeds the cost of obtaining the authorisation in the first instance.
The second common mistake is treating banking and licensing as sequential rather than parallel. Operators who complete their AFSA authorisation and then begin banking discussions are typically three to six months behind operators who run both tracks simultaneously. The compliance documents required for the AFSA application and for banking onboarding overlap substantially. Building them once and presenting them to both the regulator and the banking partner is the efficient approach.
Related at OBOLUS
- Banking, Payments and EMI Onboarding for Digital-Asset Businesses – how we map the full payment-rail stack for licensed operators
- Fiat On/Off-Ramp Banking for Early-Stage Founders – practical guidance on building fiat rails before the first licence is granted
- How to Run a VASP Business Risk Assessment – the methodology we use before any application or banking engagement
FAQ
Why do banks close crypto company accounts?
Banks close crypto company accounts primarily because the operator cannot satisfy the bank's risk-appetite requirements at the compliance-review stage. The most common triggers are: an absent or unverifiable regulatory authorisation, an AML/KYC policy that does not meet the bank's own compliance standards, an unclear client-money structure, or a beneficial-ownership disclosure that the bank cannot verify. The solution is not to find a less cautious bank – it is to build the compliance package that a cautious bank will accept. AFSA authorisation and a structured onboarding file address the most common failure points.
How can a VASP onboard with an EMI?
A VASP (virtual asset service provider) onboards with an EMI by presenting the EMI's compliance team with evidence of regulatory authorisation, a current AML/KYC policy, a client-money safeguarding explanation, and ownership and control information in a form the EMI's legal team can approve. The AFSA authorisation is the key credential for an AIFC operator, supplemented by Travel Rule compliance documentation and a clear description of the fiat flow between the EMI account and the digital-asset platform. Preparation matters more than negotiation at this stage.
What does client-money safeguarding require?
Client-money safeguarding requires an operator to hold client fiat balances in a segregated account, separate from the operator's own funds, in a manner that protects those balances if the operator becomes insolvent. The specific requirements – which institution may hold the segregated account, how often reconciliation must occur, and what disclosures must be made to clients – vary by regulatory regime and licence category. For an AIFC operator, the applicable AFSA requirements govern the segregation obligation; the EMI's home-country regime imposes a parallel obligation on the EMI itself.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance that sit around them. Digital assets are the whole of our practice. We map the licence stack across operating, custody and payment layers before you commit – and we structure licensing, banking and tax as one mandate rather than three disconnected workstreams. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory and Compliance Analyst – specialist in AFSA and cross-border digital-asset authorisation structures across the Central Asian and Middle Eastern markets.
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.