Open Banking in Georgia runs under the National Bank of Georgia and Order No. 80/04. How the framework works, which APIs are mandatory, and what it means for business.
Georgia is building one of the most deliberate Open Banking frameworks in the region. The National Bank of Georgia did not simply import a European standard. It convened a working group, spent years developing a local framework, and anchored the whole system in formal regulation. That is not a small thing. It means Open Banking in Georgia has institutional backing, a defined legal perimeter, and a clear direction of travel.
For founders, fintech operators, and businesses that collect payments or offer financial services in Georgia, understanding how Open Banking works is no longer optional. It shapes what products you can build, what data you can access with customer consent, and how payment initiation will function in the years ahead. This guide explains the framework, what it is, how it developed, what the legal rules require, and what the ecosystem looks like today. It also covers how Monetopay operates within this infrastructure to offer businesses a practical way to accept open banking payments.
Open Banking is a model in which financial institutions, primarily banks, are required or permitted to share customer financial data with authorised third parties, provided the customer has given explicit consent. The sharing happens through standardised, secure APIs. No screen-scraping. No sharing of passwords. The bank remains the data custodian; the customer controls access.
The concept emerged from regulation. In the European Union, the second Payment Services Directive (PSD2) was the catalyst; it obliged banks to open up access to account data and payment initiation services to licensed third parties. Georgia adopted a similar philosophy and built its own framework, calibrated to local market conditions but aligned in principle with international standards.
Open Banking is not a product. It is infrastructure. It enables the products, including pay-by-bank payments, personal finance tools, lending underwriting based on transaction history, and automated accounting integrations, that sit on top of it.
Open Banking represents a structural shift in how financial data is governed. In the traditional model, a customer's financial data belongs, in practice, to the bank. The customer can see it, but cannot easily move it, share it, or use it to access services from other providers. The bank is the gatekeeper.
Open Banking inverts that logic. The customer becomes the controller of their own financial data. They determine who can access it, what data is shared, and for how long. When the customer revokes consent, access ends. The data does not persist with the third party beyond the authorised period.
Technically, this is enabled through APIs, Application Programming Interfaces, which are standardised, machine-readable channels that allow one software system to request and receive data from another. A fintech application does not need to log into a customer's internet banking to read their transaction history. Instead, it calls the bank's API with a valid customer token, and the bank responds with the authorised data in a structured format.
Open Banking is not about banks losing control. It is about customers gaining it. The bank still holds the data and manages the relationship, but the customer now has the technical and legal right to share that data with whoever they choose, on whatever terms they set.
This distinction matters for businesses building on top of Open Banking. Access is conditional on customer consent, which must be informed, specific, and time-limited. A business cannot collect open banking data speculatively or without a clear customer-facing consent flow.
The practical differences between traditional and open banking models are significant. Understanding them helps clarify both the opportunity and the compliance obligations that come with operating in an Open Banking environment.
| Dimension | Traditional Banking | Open Banking |
|---|---|---|
| Data ownership | Held and controlled by the bank | Controlled by the customer |
| Third-party access | Not available or requires manual processes | Available via API with customer consent |
| Payment initiation | Only through bank channels | Third parties can initiate with authorisation |
| Consent model | Implicit or not required | Explicit, informed, time-limited |
| Innovation surface | Limited to the bank's own product team | Open to the fintech ecosystem |
| Data portability | Difficult, no standard format | Standardised API responses |
| Account information | Accessible only in the bank's own interface | Shareable with authorised providers |
In the traditional model, if a business wanted to verify a customer's income or account balance, the customer had to provide bank statements manually. The process was slow, error-prone, and created friction. In an Open Banking model, with the customer's consent and a valid API connection, that verification can happen in seconds.
For payment initiation, the difference is equally significant. Traditional card payments route through a card network, such as Visa or Mastercard, and involve multiple intermediaries. Open banking payment initiation routes directly from the customer's bank account to the recipient's account, often with lower fees and no card network dependency. Monetopay's open banking payments product operates exactly on this basis: pay-by-bank without cards, in markets where open banking infrastructure is available.
Open Banking creates value at three levels: for customers, for businesses, and for the broader financial system. The benefits are not theoretical; they are already visible in markets where Open Banking is mature.
The most foundational benefit is consent-based data sharing. A customer can authorise a fintech application to read their transaction history for 90 days. At the end of that period, access expires automatically. The customer can also revoke consent at any time through their bank's interface. This is a material improvement over the previous situation, where sharing data often meant sharing credentials.
Open Banking frameworks impose strict security requirements on every participant. In Georgia, entities participating in Open Banking must comply with the data security standards established by the National Bank of Georgia. Customer authentication follows prescribed security mechanisms, typically Strong Customer Authentication (SCA), which requires the customer to verify their identity through at least two independent factors before data sharing or payment initiation is approved.
Warning: Participating in Georgia's Open Banking ecosystem without meeting the National Bank of Georgia's authentication and data security requirements is not a grey area. Non-compliant entities are excluded from the ecosystem. Compliance is a prerequisite, not an option.
Open Banking lowers the barrier to building financial products. A startup does not need a banking licence to offer account aggregation, spending analysis, or income verification; it needs a licence to access the APIs and a compliant consent framework. This is why Open Banking environments consistently generate new financial products. In Georgia, it creates the conditions for a thriving fintech sector, with companies like Monetopay able to build payment products directly on top of the open banking infrastructure.
Payment initiation through open banking removes several layers of intermediation. There is no card network fee, no issuer-acquirer split, and no card-on-file storage requirement. For businesses with high transaction volumes, this cost difference compounds quickly. Open banking payments also tend to have higher success rates in markets where bank infrastructure is strong, because the payment instruction goes directly to the bank rather than passing through a card authorisation chain.
The development of Open Banking in Georgia has followed a deliberate, multi-stakeholder process, one that began with consultation, moved to framework development, and is now in the stage of active implementation and ecosystem growth.
At the initiative of the National Bank of Georgia, consultations and working group meetings on Open Banking began in the summer of 2019. The working group brought together representatives of the National Bank of Georgia, the Banking Association of Georgia, and commercial banks. This was not a top-down mandate handed to the industry; it was a structured process of co-design between the regulator and the institutions that would need to implement the standards.
Within the Banking Association of Georgia, an Open Banking Committee was established to develop standards, drive the project forward, and coordinate among participating parties. The committee's work, alongside the National Bank of Georgia and commercial banks, produced the first version of the Open Banking implementation framework in September 2020.
This document defines the mandatory API services that financial institutions are required to provide through secure channels. It also established that the framework is not static: it anticipates the phased addition of new API services over time, as market needs evolve and the ecosystem matures.
Georgia's Open Banking framework is built with reference to PSD2, the European Union's second Payment Services Directive, which is the global benchmark for Open Banking regulation. The mandatory minimum requirements in Georgia's framework (account information sharing and payment initiation) map directly onto the core PSD2 obligations. However, the framework also allows for additional API services beyond this baseline, giving market participants the opportunity to build richer integrations.
Georgia's Open Banking framework is not a simplified copy of PSD2. It was developed locally, with Georgian market conditions in mind, and includes provisions for additional API services that go beyond the European baseline. Businesses with experience in PSD2-compliant markets will find familiar principles, but should not assume identical rules.
As of August 2026, Open Banking in Georgia is active and continuing to develop. The regulatory and technical foundations are in place. Commercial banks are required to expose the mandatory API services. The National Bank of Georgia continues to oversee the framework's evolution, with the long-term direction pointing toward Open Finance.
The legal foundation for Open Banking in Georgia is Order No. 80/04 of the President of the National Bank of Georgia, formally titled "On Approval of the Rule on Inclusion in Open Banking." This order is the governing document for the entire Open Banking ecosystem in Georgia.
The Order sets out the rules for how entities become participants in the Open Banking ecosystem, what obligations they take on when they do, and how the system must function in practice. Its stated purpose is to regulate the process of inclusion in Open Banking and to ensure the proper functioning, reliability, and security of the services provided by all participating entities.
This covers financial institutions (which must expose the mandatory APIs) and third-party providers (which must meet the technical and compliance requirements to access those APIs). Both sides of the ecosystem operate under the Order's framework.
The current framework defines two categories of mandatory API services that financial institutions must make available:
These two categories represent the baseline, the minimum that every participating financial institution must support. The framework also accommodates additional API services beyond this minimum, and anticipates that new categories will be added over time as market demand and technical capabilities develop.
To participate in Georgia's Open Banking ecosystem, whether as a data provider (bank) or a third-party provider (fintech), an entity must meet the conditions set out in Order No. 80/04. These include technical interoperability requirements, data protection obligations, and operational resilience standards. The National Bank of Georgia oversees compliance and has the authority to exclude non-compliant entities from the ecosystem.
An ecosystem is only as useful as the rules that govern participation within it. Georgia's Open Banking ecosystem is built on a unified set of rules and standards that create a predictable, secure operating environment for all parties, customers, banks, and third-party providers.
The framework defines technical interoperability requirements, meaning that APIs must conform to a common standard so that any licensed third party can connect to any participating financial institution without bespoke integrations. This is what makes the ecosystem function as a system rather than a collection of bilateral arrangements.
Interoperability requirements cover API specification formats, authentication protocols, error handling standards, and performance expectations. A third-party provider that meets the interoperability requirements can, in principle, connect to any Open Banking-compliant bank in Georgia through the same integration.
Participating entities are obliged to meet data protection standards consistent with the National Bank of Georgia's requirements. This includes how customer consent is recorded, how long data may be retained, and what happens when a customer revokes consent. Operational resilience requirements ensure that Open Banking infrastructure is available and performant. Entities cannot offer an API that is unreliable or frequently unavailable.
Georgia's Open Banking framework is designed as a foundation, not an endpoint. The National Bank of Georgia has signalled that the ecosystem will evolve toward Open Finance, a broader framework in which data sharing extends beyond bank accounts to include insurance policies, pension products, investment accounts, and other financial data. Open Banking is the first layer. Open Finance is the direction.
For businesses building financial products in Georgia today, this trajectory matters. The infrastructure being built for Open Banking payments, including pay-by-bank products like Monetopay's open banking offering, will become part of a broader, richer data ecosystem as Open Finance develops.
Monetopay is a payment infrastructure platform built for modern businesses operating across markets. Its open banking product allows businesses to accept pay-by-bank payments without cards, without redirects, and without the fee structure of card network rails, directly through open banking infrastructure in supported markets.
All products run through one platform, one contract, and one set of credentials. Get in touch to discuss how Monetopay's open banking infrastructure can work for your business.
Open Banking in Georgia is not a pilot programme or a distant regulatory aspiration. It is active infrastructure, grounded in a legal framework, overseen by the National Bank of Georgia, and already in use by financial institutions and authorised third parties. The framework will expand toward Open Finance and toward additional API categories, and the businesses that understand it now will be better positioned to build on it as it grows.
The core logic is simple: customers own their financial data, banks provide standardised access, and licensed third parties can build products on top of that access with customer consent. That logic creates a new surface area for financial product development in Georgia. Payment initiation, account verification, income analysis, lending underwriting, and automated reconciliation are all enabled by this infrastructure.
If you are building a product that touches Georgian financial infrastructure, or if you want to accept open banking payments from customers without card rails, get in touch with Monetopay. One platform. All payment methods. One integration.
Open Banking covers the sharing of bank account data and the initiation of payments from bank accounts, with customer consent. Open Finance is a broader concept that extends the same data-sharing logic to other financial products, insurance policies, pension accounts, investment portfolios, and more. In Georgia, the current framework is Open Banking. Open Finance is the stated long-term direction.
The National Bank of Georgia is the primary regulator and overseer of the Open Banking framework. It initiated the working group in 2019, co-developed the implementation framework with the Banking Association of Georgia and commercial banks, and issued Order No. 80/04, which is the governing legal instrument for the entire ecosystem. The National Bank of Georgia also monitors compliance and can exclude non-compliant entities from participation.
At a minimum, Georgian financial institutions participating in Open Banking must expose two categories of API services: account information services (which allow licensed third parties to read customer account data with consent) and payment initiation services (which allow licensed third parties to initiate payments from customer accounts with consent and authentication). The framework also permits additional API services beyond these mandatory categories.
No. A banking licence is not required to access Open Banking APIs as a third-party provider. However, the entity must meet the participation requirements set out in Order No. 80/04, including technical interoperability standards, data protection obligations, and authentication requirements. The National Bank of Georgia must recognise the entity as a qualifying participant before API access is granted.
Consent must be explicit, informed, and time-limited. This means the customer must actively agree to share their data, must understand what data is being shared and with whom, and must have the ability to revoke consent at any time. Consent cannot be bundled with other terms or obtained implicitly. When the authorised period ends, access expires automatically. Ongoing access requires renewed consent.
Payment initiation is the ability of an authorised third party to trigger a payment from a customer's bank account on their behalf, with the customer's consent and following authentication. Unlike a card payment, which routes through a card network, an issuing bank, and an acquiring bank, an open banking payment goes directly from the payer's bank to the payee's account. This removes several layers of intermediation, typically reduces fees, and eliminates the need for card details. Monetopay's open banking product operates on this basis.
Georgia's framework was developed with reference to PSD2 and shares its core logic, the same two mandatory API categories (account information and payment initiation), the same consent model, and similar authentication requirements. However, it is a locally developed framework, not a direct transposition of PSD2. There are differences in implementation detail, and Georgia's framework includes provisions for additional API services that go beyond the PSD2 baseline.
Payment infrastructure team at Moneto LLC, Tbilisi
monetopay is operated by Moneto LLC, a payment service provider registered with the National Bank of Georgia (reg. № 0107-7704).
Reach the team directly. We usually reply same-day.
Get in touch
A payment service provider (PSP) moves money between a customer’s bank and a merchant, handling authorisation, verification, and settlement. Here’s how PSPs work.
Monetopay is now a registered payment service provider with the National Bank of Georgia. What the PSP licence covers, and what it means for businesses.
