AML/CFT Policy Drafting in Kazakhstan (AIFC)
Operating a digital-asset business inside the Astana International Financial Centre (AIFC) without a defensible AML/CFT policy is among the fastest routes to a suspended licence and frozen banking rails. The Astana Financial Services Authority (AFSA) – the AIFC's financial regulator – applies a common-law compliance standard that borrows from FATF Recommendation 15 and expects documented, risk-based controls before a firm admits its first client. For an inbound exchange, custodian or token platform, this means the policy framework must be drafted, tested and embedded before regulatory review begins, not after the licence is granted. This page maps the regulatory basis, the practical drafting process and the cross-border complications that most operators discover too late.
The AFSA AML/CFT Framework and Why It Differs From Other Hubs
The AIFC operates under a distinct common-law regime inside Kazakhstan, and AFSA's AML/CFT expectations are grounded in FATF standards – particularly the requirements for virtual-asset service providers set out under FATF Recommendation 15 – but applied through AIFC-specific rulebooks rather than Kazakh national law. That distinction matters immediately for any operator planning a cross-border structure. A firm licensed in the AIFC is not automatically compliant with Kazakhstan's national AML regime, and vice versa. The two bodies are separate, and a policy designed for the national framework will not satisfy AFSA on its own.
AFSA expects a written, risk-based AML/CFT policy that is proportionate to the firm's actual activity profile. A custody business carries different inherent risks than a trading facility. AFSA's published framework addresses customer due diligence, enhanced due diligence for higher-risk relationships, transaction monitoring, suspicious activity reporting, record retention and – critically for digital-asset businesses – the Travel Rule (the obligation under FATF standards to pass originator and beneficiary data with every qualifying transfer). In our practice, the firms that attract the most scrutiny during AFSA review are those whose written policies are imported from another jurisdiction without adaptation to the AIFC's specific rulebook definitions and thresholds.
The AIFC common-law foundation also shapes how policy documents are read by reviewers. AFSA examiners approach documentation with a degree of legal precision more consistent with English regulatory practice than with continental civil-law supervision. Vague or aspirational language – the kind that passes muster in some offshore centres – draws specific written questions and, in the worst cases, a request to restart the drafting process.
Operators we advise routinely discover that the AIFC's rulebook definitions of "beneficial owner," "politically exposed person" and "correspondent relationship" differ in scope from the definitions they already use in their EU or UK compliance manuals. Aligning those definitions at the drafting stage, not at the examination stage, is where the work lives.
Who Needs an AML/CFT Policy in the AIFC?
Any AFSA-regulated firm carrying on digital-asset activities – including digital-asset trading facility operators, custodians, exchange services and any business providing transfer or settlement services for virtual assets – requires a standalone AML/CFT policy as a condition of authorisation. The obligation is not limited to firms with a high transaction volume. AFSA applies the requirement across licence categories without a de-minimis carve-out for small or early-stage businesses.
This catches several operator profiles that do not always self-identify as needing a full compliance programme. A token issuer that distributes to AIFC-regulated participants may require policy documentation even if it does not hold client assets directly. A firm that uses the AIFC as its holding or management entity – while the actual exchange is licensed elsewhere – can still fall within AFSA's supervisory perimeter if the AIFC entity is sufficiently involved in directing the group's regulated activity.
The cross-border dimension is particularly sharp here. An operator whose parent sits in a stricter regime (say, a MAS-licensed Singapore entity) may assume that the group AML policy satisfies AFSA. In practice, AFSA requires a policy that addresses the AIFC entity's own risk profile, its own customer base and its own transaction flows. A group policy reference is acceptable as a starting point, but not as a substitute for a jurisdiction-specific document.
AFSA's VASP framework covers digital-asset trading facility operations and custody services within the AIFC free zone, and the AML/CFT policy obligation attaches at the point of authorisation application – meaning the document must exist before approval, not as a post-authorisation deliverable.
For a scoped policy-drafting engagement, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity structure, the user base, the banking relationships and the group's existing compliance architecture – change the analysis materially. Map your options.
What a Compliant AML/CFT Policy Must Cover
A compliant AFSA AML/CFT policy is not a single document. It is a suite of interconnected written procedures that together demonstrate a risk-based approach to money laundering and terrorist financing. The core components are fixed; the calibration of each component to the firm's risk appetite is what distinguishes a document that passes review from one that generates a remediation cycle.
The policy suite typically comprises: a risk assessment (the foundation document that informs every control downstream); a customer due diligence and know-your-customer procedure; an enhanced due diligence procedure for higher-risk relationships; a politically exposed person screening protocol; a transaction monitoring procedure specifying how alerts are generated, escalated and resolved; a suspicious transaction reporting procedure naming the Money Laundering Reporting Officer (MLRO) and the internal escalation path; a record retention schedule; and – for any business moving digital assets between platforms – a Travel Rule procedure that specifies how originator and beneficiary data is collected, verified and transmitted.
The risk assessment is the document AFSA examiners read first, and it is the one most frequently under-developed. A credible risk assessment maps the firm's products, delivery channels, customer types and geographies against a set of threat scenarios and concludes with a written rating – high, medium or low – for each risk category. It must be a live document, subject to periodic review and updated whenever the firm's product or customer profile changes materially.
Transaction monitoring deserves particular attention for digital-asset businesses. AFSA expects that monitoring is applied to on-chain activity as well as off-chain flows. That means the policy must address how the firm handles blockchain analytics – which tools are used, how alert thresholds are set, and how on-chain risk indicators (exposure to sanctioned addresses, mixer usage, high-risk counterparty flags) feed into the firm's customer risk rating system.
Travel Rule Obligations in the AIFC: The Practical Complications
The Travel Rule – as applied to AFSA-regulated entities – requires that virtual-asset transfers above the applicable threshold carry originator and beneficiary data. The operative principle derives from FATF guidance on virtual assets, and AFSA has incorporated it into the AIFC's VASP framework. What complicates execution is not the rule itself but the counterparty problem: a Travel-Rule-compliant transfer requires that the receiving VASP (virtual asset service provider) can accept and process the data.
In our cross-border practice, the Travel Rule implementation question splits into three distinct problems. First, there is the protocol selection question: which messaging standard does the firm use to transmit originator/beneficiary data (IVMS 101 being the dominant data standard), and how does that integrate with the firm's transaction processing infrastructure. Second, there is the counterparty identification problem: when a client sends funds to or receives funds from a VASP in a jurisdiction that has not yet implemented the Travel Rule, the AFSA-regulated firm still carries the obligation to make reasonable efforts to collect and transmit data. Third, there is the unhosted-wallet question: transfers to or from wallets not held at a regulated VASP require the firm to have a documented procedure for handling that transaction type, which typically involves enhanced due diligence on the beneficial owner of the unhosted address.
Each of these problems must be addressed in the written policy, not handled ad hoc at the transaction level. AFSA reviewers will ask specifically how the firm resolves each scenario, and "we assess it case by case" is not an acceptable written answer without an underlying decision framework in the policy documentation.
A Travel Rule procedure that works for the AIFC entity must also account for the group's exposure to other regimes. If the same group holds a Singapore DPT licence under the MAS Payment Services Act, its Travel Rule obligations under MAS may differ in threshold, data field requirements and record-keeping period. A cross-entity policy must flag those divergences explicitly rather than paper over them with a single global standard that satisfies neither regulator fully.
The MLRO and Governance Requirements
AFSA requires every regulated digital-asset business to appoint a named Money Laundering Reporting Officer who is responsible for the firm's AML/CFT compliance programme and serves as the primary point of contact for AFSA on supervisory matters. The MLRO must have sufficient seniority, authority and access to information to perform the role effectively. AFSA will scrutinize the MLRO appointment as part of the fit-and-proper assessment that accompanies the authorisation process.
In practice, the MLRO question is one of the most operationally difficult for early-stage or founder-led businesses. A founding team based in a different time zone from Astana, with no local presence, will struggle to satisfy AFSA that the MLRO has genuine operational authority and is not a nominal appointment. AFSA's expectations here track the substance-over-form approach: the regulator is interested in whether the MLRO can actually act, not merely whether the name appears on an organogram.
The AML/CFT policy must document the MLRO's mandate in specific terms: decision-making authority over account suspensions; ability to file suspicious transaction reports directly with the relevant authority; access to all transaction data and customer records; and a clear escalation path to the board or equivalent governing body. Where the MLRO is the same person as a founder or executive, the policy must also address how conflicts of interest are managed in the escalation process.
Board-level oversight of the AML/CFT programme is a separate requirement. AFSA expects that the governing body reviews the programme periodically, receives management information on compliance metrics and suspicious activity reporting, and formally approves material changes to the policy suite. That oversight obligation must be reflected in the written policy and, separately, in board minutes and committee terms of reference.
Cross-Border Banking and Tax Interactions With the AML/CFT Architecture
An AFSA-licensed firm that handles the AML/CFT policy in isolation – without considering how it interacts with the firm's banking relationships and tax structure – will face a second set of problems once the licence is active. Banking is the area where this becomes immediately commercial.
Correspondent banks and digital-asset-friendly banking partners assess an AIFC-licensed firm's AML/CFT policy as part of their own onboarding due diligence. A policy that satisfies AFSA's regulatory minimum but lacks the operational detail that a compliance officer at a correspondent bank expects – granular transaction monitoring thresholds, a documented sanctions screening process, a named MLRO with contact details – will cause delays and, in some cases, account refusals. In our practice, we have seen AFSA-licensed firms with technically compliant policies unable to open operating accounts because the policy document was written for a regulatory reviewer rather than for a banking compliance team.
The tax interaction is less direct but equally important. Many AIFC-licensed digital-asset businesses are part of a multi-entity group that includes holding structures in other jurisdictions. The AML/CFT policy's customer identification and beneficial ownership records feed directly into the tax compliance picture – transfer pricing documentation, substance requirements and the Common Reporting Standard (CRS) all depend on the accuracy of the records that the AML/CFT programme generates. A policy with gaps in beneficial ownership identification creates downstream exposure not just for AML purposes but for the group's tax position in every jurisdiction where it has a presence.
If a prior application stalled or a banking account was closed after an AIFC authorisation, a structural review can often surface the root cause. Write to info@oboluslaw.com to discuss a second-look engagement, or Map your options.
What Goes Wrong: Common Mistakes in AIFC AML/CFT Policy Drafting
A common assumption is that a well-drafted policy from a comparable jurisdiction – a MiCA-ready EU policy, for instance, or a Singapore DPT policy – can be lightly adapted for AFSA submission with only cosmetic changes. That assumption is wrong in ways that matter. The AIFC's rulebook definitions, the specific risk indicators AFSA considers material for the Central Asian market context, and the governance expectations embedded in AFSA's authorisation framework all diverge enough from EU and Singapore standards to require substantive reworking rather than find-and-replace editing.
The second most common mistake is treating the AML/CFT policy as a one-time deliverable rather than a living compliance programme. AFSA conducts supervisory reviews, and a policy that has not been updated to reflect changes in the firm's product range, customer base or transaction volumes will fail the review. The policy must include a documented review cycle – typically annual at minimum, with trigger-based reviews when material changes occur – and evidence that the cycle has been followed.
Third, and perhaps most damaging for firms with ambitions to grow the AIFC entity into a regional hub: a policy that does not address correspondent VASP relationships and the AML risks they introduce will create a supervisory gap that becomes harder to close as the business scales. Every VASP-to-VASP relationship should be assessed and documented, with enhanced due diligence applied where the counterparty's own AML standards are unclear or sub-FATF.
In a recent matter, a fintech business expanding from a Gulf hub to the AIFC submitted a policy that had been drafted for its home jurisdiction. AFSA's review identified several provisions that directly contradicted the AIFC rulebook's definitions of customer due diligence obligations. The result was a multi-month delay while the firm redrafted the core procedures. We were engaged after the fact, and the remediation took considerably longer than an initial drafting engagement would have. The lesson is consistent: jurisdiction-specific drafting from the outset costs less than remediation under regulatory pressure.
Related Practices at OBOLUS
Related at OBOLUS
- AML/CFT and Travel Rule compliance for digital-asset businesses – end-to-end compliance programme design across the major licensing hubs
- Travel Rule compliance programme in Canada – comparative Travel Rule implementation for cross-border VASP operations
- Staking and rewards taxation for digital-asset firms – tax structuring counsel where the compliance and tax records interact
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule – derived from FATF Recommendation 15 – requires a VASP to collect, verify and transmit originator and beneficiary information with every qualifying virtual-asset transfer. The data standard most widely adopted is IVMS 101. In the AIFC, AFSA incorporates the Travel Rule into its VASP framework, meaning the obligation applies from day one of regulated activity. The specific transfer threshold varies and should be confirmed against current AFSA guidance at the time of implementation.
Who must act as MLRO for a crypto firm?
The MLRO must be a named individual with genuine authority over the firm's AML/CFT programme, direct access to all customer and transaction records, and the ability to file suspicious transaction reports without requiring approval from a superior. AFSA assesses the MLRO as part of its fit-and-proper review. A nominal or offshore-based MLRO without real operational authority is unlikely to satisfy AFSA's substance expectations. For early-stage firms, designing the MLRO governance structure before the authorisation application is submitted is strongly advisable.
How do regulators audit crypto AML programs?
AFSA and equivalent regulators typically audit AML/CFT programmes through a combination of document review, management interviews and transaction-file testing. Examiners assess whether the written policy matches the firm's actual operating procedures, whether transaction monitoring is functioning and producing meaningful alerts, and whether suspicious activity reporting is timely and well-documented. Gaps between the written policy and operational reality – including outdated risk assessments and MLRO reports that have never been presented to the board – are among the most common findings in supervisory reviews.
About OBOLUS
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 architecture that sits around them. Digital assets are the entirety of our practice. We map the licence, compliance and banking stack across operating, custody and payment layers before a client commits – not after a problem surfaces. To discuss your AML/CFT programme for the AIFC or any other hub, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML/CFT programme design and regulatory authorisation strategy for digital-asset businesses across the AIFC, EU and Gulf hubs.
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.