Lithuania · Regional page
Open banking Lithuania: one service layer for Lithuanian banks
Lithuania has more licensed payment institutions than most markets of its size, which makes the choice of who initiates a payment and who holds the receiving account unusually open. viaBanking puts one service layer in front of both. Licensed providers initiate the payment on the payer's consent, and we confirm in read-only mode that the amount reached the C2B account your company holds.
- OneService layer covering banks and EMIs in this market
- Read-onlyConfirmation of the credit on your own C2B account
- LicensedEvery regulated service delivered by a licensed institution
- Any supportedProvider can be paired with any integrated account
The platform
What one service layer is for
One service layer, many institutions behind it
Your product talks to a single open banking API. Behind it sit the licensed providers that reach Lithuanian banks and the institutions that hold C2B accounts, and neither of those choices reaches into your code. Their services are ours to orchestrate, not yours to integrate one after another.
Provider and account chosen separately
Which provider initiates and which institution holds the receiving account are two independent questions here. Any supported provider works with any integrated account on the platform, and changing one does not disturb the other.
One payment model whatever the pairing
Every combination reports the same fields, the same status names and the same confirmed credit event, so your reconciliation service is written once and reused for other markets.
The credit confirmed on your own account
A licensed AIS provider performs a read-only account information service against the C2B account your company holds, and we raise one event per payment when the expected amount arrives. Most open banking services stop one step earlier than this.
Definition
Three roles in a Lithuanian bank payment
The framework behind it is described on the PSD2 open banking page.
- 01
Banks provide the access interface
Banks in Lithuania operate a regulated open access interface that a licensed institution may call on a customer's instruction. It accepts a payment request and returns payment status, and it exists because European rules oblige the bank to provide it rather than because any vendor negotiated for it. Open banking services in this market all rest on that same interface.
- 02
The customer consents inside their bank
A payer selects their bank, authenticates there and approves the amount and the beneficiary. That approval is the user's payment consent, and no banking credential passes through your service or ours.
- 03
Regulated services stay with licensed institutions
Payment initiation is a regulated service delivered by a licensed PIS provider. The read-only account information service behind the account credit confirmation is delivered by a licensed AIS provider. Both are regulated services and neither belongs to us. viaBanking supplies the open banking software layer between them and sells no regulated services of its own.
Use cases
Who uses this service from Lithuania
Payment businesses based in Lithuania
Companies whose own product is financial, collecting from customers through open banking services and choosing the account institution that suits their reporting and their currencies rather than the one another vendor bundled.
Software billing European customers
Annual plans and enterprise renewals paid by bank transfer, with the contract reference carried through to the credit event and no other reconciliation step in between.
Marketplaces across the Baltic markets
One payment model for buyers in three countries, so the platform ledger does not grow a set of per market exceptions as other markets are added.
B2B invoicing
Payment links that open the payer's own bank with the amount and the reference already set, which removes the retyping that makes manual transfers go wrong. Open banking services suit this pattern better than any other method.
Companies consolidating provider contracts
Businesses carrying several provider agreements can route them through one service layer and keep the relationships that are worth keeping, dropping the others without touching their integration.
Integration
One pairing, then five steps per payment
- 1
Choose the pairing
A supported licensed provider and an integrated institution to hold the C2B account.
- 2
Create the payment
One call carrying an amount, a currency, a reference and the destination account.
- 3
The payer approves
Bank selection, then consent and authentication inside their own Lithuanian bank.
- 4
Status arrives normalised
Whatever the provider called the outcome, your systems receive one vocabulary.
- 5
The account credit is confirmed
A read-only check raises one event when the expected amount reaches your own account.
- 1Service layer your engineers integrate and maintain
- 2Independent choices: the provider and the account
- 0Code changes when either of those choices changes
The problem
What happens when choice goes unmanaged
- 1
More institutions means more agreements
In a market with this many licensed institutions, a company can easily end up holding three provider agreements and two account relationships, each with its own reporting and its own service contact. Choice is useful, and unmanaged choice is expensive in a way no other part of a payment stack quite matches.
- 2
Each contract brings its own format
Every provider names open banking payment outcomes differently and reports them on its own schedule. Without a normalising layer, the finance team maintains one translation per agreement rather than one payment model for the business, and each other agreement adds another.
- 3
Nobody owns the whole picture
When a payment does not resolve, the answer is split between a provider, an institution and your own systems, and each of them can only see its own part. Support conversations of that shape take days rather than minutes, and the customer waits through all of it while the other parties compare notes.
Market context
Lithuania as an electronic money hub
This section is background about the market, included because it genuinely changes what options a company has here. It is not advice, and it is not a service we sell.
An unusual concentration of licensed institutions
Lithuania hosts a large number of authorised electronic money institutions and payment institutions relative to its size. A deliberate policy of licensing fintech businesses over the past decade produced that concentration, and it shapes how payment arrangements are put together here.
Why the account choice is wider here
Where many institutions operate, a company has genuine options for the account that receives its money: currencies supported, reporting quality, onboarding requirements and the commercial relationship itself. In most markets that choice is narrow, and in Lithuania it is not.
What this does not mean
It does not mean any institution can be used. It means any institution already integrated with the platform can hold the C2B account, and each one still contracts directly with your company. viaBanking does not introduce, endorse or name specific Lithuanian institutions as partners, and does not advise on licensing.
Capabilities
Six capabilities and their owners
| Capability | What it covers | Owned by |
|---|---|---|
| Provider selection | Any supported licensed provider reaching the payer's bank | Configured with viaBanking |
| Account selection | Any integrated bank or EMI holding the C2B account | Contracted by your company |
| Payment initiation | A regulated service on the user's payment consent | Licensed PIS provider |
| Authentication | Inside the payer's own Lithuanian bank | The payer's bank |
| Status normalisation | One vocabulary across every provider and pairing | viaBanking |
| Account credit confirmation | Read-only account information service on your own account | Licensed AIS provider, surfaced by viaBanking |
Security and consent
The limits of the permission we use
The bank keeps the credentials
Authentication happens inside the Lithuanian bank the payer selected. No credential, code or device confirmation reaches viaBanking or your service, whichever provider carried the payment.
One consent per payment
It names an amount, a beneficiary account and a reference, and it ends when the payment resolves. It grants nobody a continuing right to read the payer's account.
Read-only, on your account alone
The account information service is scoped to the C2B account your company holds. It recognises an expected account credit and nothing more. It cannot manage the account, cannot move money and never touches the payer's account.
FAQ
Six questions about the Lithuanian route
-
How does open banking work in Lithuania?
Your product creates one payment through a single service layer, the payer approves inside their Lithuanian bank, a licensed provider performs the initiation, and viaBanking confirms in read-only mode that the amount reached your own C2B account. The number of institutions in the market is handled behind the layer rather than in your integration.
-
Why is there more choice of institution here?
Lithuania authorised a large number of electronic money and payment institutions over the past decade, and many of them operate from there. That gives a company real options for the account that receives its money. It is market context rather than a recommendation, and viaBanking does not name or endorse specific institutions.
-
Which Lithuanian banks are reachable?
Reach comes from the licensed providers behind the route and covers the main Lithuanian banks along with institutions that vary by provider. We check your customers' actual banks against live coverage before you build, rather than publishing a figure the product has not confirmed.
-
Who holds the licence on this route?
The PIS provider performing the payment initiation, the AIS provider performing the read-only account check, and the bank or EMI holding the accounts. viaBanking is a software company: it holds no authorisation, executes no payments and does not move or hold funds.
-
How is the arrival of money confirmed?
Through a read-only account information service on your own C2B account, which raises one event when the expected amount is credited. It is a check on your business account only, and it never reads the payer's account, their balances or their transaction history.
-
What does a company need at the start?
An account with an integrated institution to receive the funds, contracted directly with it, and engineering capacity to handle payment statuses. Documentation and support are in English, which matters for the international teams that typically run these projects. Neighbouring markets are covered on the Latvia and Estonia pages, and the regional view on the Europe page.
Choose the provider and the account on their own merits
Tell us which Lithuanian banks your customers use and what the receiving account has to do for your business. We come back with the supported combinations that fit and with live open banking coverage behind each of them. Documentation and support are in English, and if open banking services are the wrong answer for what you sell, we will say so rather than sell you an integration that competes with something already working.
viaBanking is a software and technology provider. Regulated payment initiation and account information services are delivered by licensed partner institutions. viaBanking does not hold an AIS or PIS licence, does not execute bank payments and does not move funds.