Laos has launched a fintech sandbox framework to encourage the use of innovative technologies in financial services. The Bank of the Lao PDR (BOL) issued Decision on the Testing of Financial Technology No. 170 (ຂໍ້ຕົກລົງ ວ່າດ້ວຍການທົດສອບເຕັກໂນໂລຊີດ້ານການເງິນ), published in the Lao Official Gazette on March 10, 2026, and now in force.
The sandbox provides a controlled, supervised environment to deploy and test fintech services in practice before going live on a larger scale. This is not the first time Laos has had recourse to a fintech testing program, but this iteration differs in one notable respect: it remains in force until the BOL decides to amend or repeal it, whereas previous programs were limited to a defined period and a restricted pool of participants.
This new regulation comes amid multiple signs of the country’s drive toward digitalization, from political announcements to recent publications of concrete regulations targeting the digital industry.
The following covers selected highlights of the Decision, rather than an exhaustive review.
I. Definition, Scope, and Eligibility Requirements
A. Defining the Framework
Like many Lao regulations, the Decision opens by establishing key terms. The expression “testing of financial technology”, which the Decision is named after, is defined as follows (Article 2):
Testing of financial technology means applying to participate in financial technology testing through the use of innovation to develop financial services, comprising deposit services, credit services, and payment services.
This definition should be read alongside the definition of financial technology itself (Article 3 (1)):
Financial Technology means the use of currently existing technology or newly created technology to develop and improve products, tools, or operational processes for financial services so that such services become more efficient, or to create new forms of financial services.
Financial technology, as defined above, corresponds to what is commonly referred to as fintech. This term will be used throughout this article.
Together, these two definitions give a clear indication of the financial services scope of the sandbox program, which is examined further below.
B. What the Decision Covers
1. Purpose and Scope
The stated purpose of the Decision is to make financial services “convenient, safe, modern, and effective” (Article 1). The regulation is primarily framed around financial institutions, fintech operators, and service users, pointing toward business-to-consumer and business-to-business models. That said, the Decision does not explicitly exclude the testing of e-government services developed by a fintech operator (e.g., facilitating tax or fee collection systems) provided such services fit the purpose and eligibility criteria of the Decision, although the private sector framing of the Decision makes this uncertain. Whether the Department of Payment Systems Management in the BOL (DPSM), the authority responsible for authorization to participate in the sandbox, would consider such applications in practice remains to be seen.
2. Scope of Fintech Services
The sandbox covers three categories of fintech services: deposit, credit, and payment services. No specific technology is prescribed or favored, although eligible technologies must meet certain characteristics (see further below).
While insurance is sometimes associated with fintech, the Decision makes no reference to it. This is consistent with the institutional framework in Laos: the present sandbox is overseen by the BOL, while insurance matters fall under the purview of the Ministry of Finance.
C. Eligibility Requirements
1. Eligible Participants
The sandbox program is open to financial institutions and non-financial institution entities (Article 7). In either case, a local footprint appears to be required. Financial institutions must be licensed by the BOL, which typically refers to locally established institutions. For non-financial entities, an Enterprise Registration Certificate, a certificate confirming the registration with the company registrar in Laos, is required at the time of application (Article 8(2.2)).
Notably, nothing in the Decision explicitly prevents participants from collaborating with offshore fintech players having no local presence, which leaves the door open to international collaboration.
2. Eligible Fintech Projects
Qualifying Characteristics
The Decision provides 10 characteristics that the fintech must meet (Article 5).
- Characteristics safeguarding national sovereignty, financial stability, and legal compliance. For instance, the technology must (1) reduce cash usage and promote the use of Lao kip, the national currency, (2) not affect the stability of the financial institutions and the monetary stability of the country, and (3) prevent money laundering, financing of terrorism, and evasion of compliance with the law.
- Other characteristics directly impact the profile of the eligible fintech. The fintech must be (4) new in Laos, (5) increase the efficiency of existing financial services, (6) promote access to, or remedy shortcomings of financial services, (7) allow its development into a shared infrastructure or a central standard for the banking sector that service providers in Laos can implement in a uniform manner, and (8) promote competition in the market, or aim to enter the market in the future.
- Other characteristics involve discretion from the BOL. The fintech must (9) be a technology or innovation that needs to be tested before being released on the market, as determined by the BOL on a case-by-case basis, and (10) the BOL retains the power to require additional characteristics.
Are all the characteristics cumulative? The Decision does not specify if all characteristics must be satisfied. Given the diversity of the criteria, a strictly cumulative reading would probably be impractical. Some characteristics are likely mandatory (e.g., financial and monetary stability). For other characteristics it may depend on the profile of the fintech and the BOL’s assessment. How the BOL applies these characteristics in practice remains an open question. Practice will tell.
II. From Application to Exit
A. Triggering the Authorization Process
1. Conditions for Authorization
To take part in the sandbox program, eligible participants must obtain authorization from the DPSM (Article 7). Being an eligible entity is not sufficient as participants must fulfill some conditions.
Financial institutions must demonstrate a clear innovation development plan, sufficient and verifiable funding, adequate staffing, and solid IT infrastructure covering service continuity, cybersecurity, and data security. Additional conditions may be set by the BOL on a case-by-case basis. Notably, the Decision provides no specific standard or benchmark against which the DPSM will assess infrastructure and security readiness, leaving some discretion to the regulator. These requirements will likely be refined through practice over time.
Non-financial institution participants must, in addition to the above, have at least one Lao national manager domiciled in Laos who has never been convicted by a court.
2. Supporting Application Documents
To obtain authorization. An application must be submitted to the DPSM with supporting documentation covering various aspects, and overall, the following (Article 8):
To obtain authorization. An application must be submitted to the DPSM with supporting documentation covering various aspects, and overall, the following (Article 8):
- Technical aspects. This includes information on the security of the system to be tested, its architecture design and development, the authentication mechanisms in place, and data storage management.
- Business and financial information. A certificate evidencing the source of funds used for the testing is required, along with information on the business model and expected benefits.
- Information on the scope of the testing and beyond. Participants must provide a testing plan covering the testing period, the target group, the management of service users during testing, the assessment methodology, and termination procedures. A risk response plan for the testing period must also be included, alongside a general risk management plan and specific key success indicators. A post-exit plan and an operational plan for the transition period are additionally required.
- Parties involved. Copies of cooperation agreements with testing partners, business partners, or external service providers must be provided, if any. Such agreements must clearly define each party’s responsibilities, including confidentiality obligations.
- Additional information for non-financial entities. Criminal record certificate, CV and residence certificate of the applicant and the manager, copy of the share register book, and financial reporting documents of the preceding year, except for newly established enterprises.
3. Term of the Authorization and Possible Extension
If accepted, the participant is granted a testing period of up to one year, extendable once for an additional year, bringing the maximum total testing period to two years (Article 10). The authorization is specific to the scope, services, and target service users described in the application. Any amendment to it requires prior authorization from the DPSM.
Extension is not automatic. To request one, participants must submit a report on the testing results, the status of service provision, and any difficulties encountered during the testing period. On a more quantifiable note, at least 70% of the indicators determined by the DPSM must have been achieved (Article 10).
B. During and After the Testing Period
1. Ongoing Obligations and Oversight
Participants are subject to ongoing obligations throughout the testing phase. Among these, a monthly report must be submitted to the DPSM in a form prescribed by the department (Article 12). The Decision does not specify the content of that form. The DPSM must also conduct at least one on-site inspection during the testing period (Article 13).
2. Exit Scenarios
The Decision anticipates three exit scenarios: (1) testing is completed within the agreed testing period, (2) testing is not completed within the agreed testing period, and (3) the participant exits the testing program before the agreed testing period.
Testing is completed within the testing period (Article 15)
Where the participant has been able to implement the technical plan and comply with DPSM regulations, the testing is deemed completed within the testing period. The DPSM then issues a certificate of successful completion. Successful completion does not automatically grant authorization to provide the service to the general public but opens the way to apply for one.
Testing is not completed within the testing period (Article 16)
When testing is not completed within the specified period, the participant must submit a report covering the testing results and explaining why the period was not met, together with a plan for future implementation if intending to reapply. The DPSM then issues a formal notice of exit.
Exit the testing program before the testing period (Article 17)
Early exit may occur in three situations: (1) the participant voluntarily exits the sandbox before the end of the testing period, (2) the DPSM directs the participant to exit when the fintech being tested has a direct or indirect impact on service users or affects financial and monetary stability, and (3) the testing is not conducted in compliance with applicable laws and regulations.
In all exit scenarios, service users must be notified of the termination of financial services at least 30 days before the exit date. Where applicable, settlement and clearance, compensation for damages, and the return of any funds remaining in the system to service users must be carried out before the exit date (Article 18).
III. Other Obligations Beyond the Testing Process
Protection of service users’ data (Article 20). The Decision provides explicit duties on participants to protect service users’ personal data. Access controls must be in place to ensure that only authorized persons can access relevant data. Users’ data cannot be used without their prior authorization, and personal data must remain confidential throughout the testing period and beyond, except in circumstances defined by the Decision, such as legal proceedings or disclosure to regulators.
Participants must also retain data, documents, and electronic records relating to the testing for at least ten years after the transaction or contract has been completed or terminated.
Dispute Resolution (Article 22). Participants must establish a formal dispute resolution mechanism, including designated contact channels for service users, and defined procedures and timeframes. Once a complaint or dispute is received, the participant has seven days to acknowledge it, inform the service user of the process, and provide a resolution timeline. The dispute must then be resolved and the service user notified promptly upon completion.
Disclaimer
This article is for general informational purposes only and does not constitute legal advice. For legal assistance or advice regarding law matters in Laos, readers must contact a qualified Lao lawyer.
Translation Note
This article is based on an independent reading of the official Lao text. This is not an official translation. While every effort has been made to ensure accurate and contextually appropriate terminology, some terms may be subject to refinement as legal usage and official interpretations evolve. If readers have a more accurate translation supported by reliable sources, comments are welcome, either in discussion or by private message.