Latvia · Regional page
Open banking Latvia: bank payments and C2B accounts on one API
Every open banking payment produces two facts, and most integrations only ever see the first. A licensed provider tells you the instruction was accepted. Separately, a read-only check on your own C2B account tells you the money arrived. This page is about the distance between those two facts in the Latvian market, and about what a business can safely do in between them.
The gap
What sits between initiation and arrival
This is the part of open banking payments that most product teams discover after launch rather than before it. It is not a Latvian peculiarity: the same gap exists in every market where open banking payments run. Latvia is simply where we explain it in full, because the mechanics matter more here than any new feature list would.
- 01
An accepted instruction is not a credited amount
When a licensed provider reports that a payment was accepted, it is telling you what the payer's bank said about the instruction. That is a real and useful fact. It is a fact about a message, and the money arriving on your own account is a separate fact that nobody in the chain has yet reported.
- 02
Most integrations stop at the first fact
The overwhelming majority of open banking payments in this market are treated as complete on the provider status: the order is released, the balance unlocked, the invoice marked paid. It works most of the time, which is precisely what makes the remaining cases so expensive to discover in production, and why teams keep rediscovering them in each new market they open.
- 03
The gap is where the awkward cases live
Open banking payments can be accepted and then not arrive. They can arrive later than the session that started them. They can arrive with a reference that a bank truncated somewhere along the way. Every one of those becomes a new support ticket when the only signal you have is the acceptance message.
- 04
Finance closes the gap by hand
Where no confirmation service exists, somebody opens a banking screen and matches incoming payments against expected ones. That work does not appear in any payment cost calculation, and it grows in a straight line with the volume of open banking payments the market sends you.
Definition
How a Latvian bank payment is assembled
The bank runs the access interface
Latvian banks operate a regulated interface that a licensed institution may call on a customer's instruction. It carries the payment request in and payment status back out. Open banking in Latvia rests on that obligation rather than on any commercial arrangement between a bank and a vendor.
The payer consents inside their bank
A payer in Latvia selects their bank, authenticates there and approves the amount and the beneficiary account. That approval is the user's payment consent, and no banking credential passes through the merchant or through viaBanking. Open banking payments look the same to a payer in every market, which is part of why the Latvian market adopted them without much friction.
Two licensed services, two different jobs
A licensed PIS provider performs the payment initiation. A licensed AIS provider performs the read-only account information service that confirms the credit on your own account. They are separate services under separate permissions held by separate institutions, and viaBanking holds neither. Nothing about that division changes when you add a new market.
The European framework behind this is described on the PSD2 open banking page.
The platform
Closing the gap without adding work
Both signals, delivered as one payment story
Your systems receive the provider status and, separately, the confirmed credit event. One payment, two facts, in a defined order, on any supported open banking route in the Latvian market. Nothing new has to be built when you add another market.
Confirmation on your own account only
The read-only account information service runs against the C2B account your company holds. It answers one question: has the expected amount been credited. Nothing about the payer's account is read, requested or stored, in Latvia or in any other market.
Reference matching handled here
Where a bank truncates or alters a reference, the matching service sits in our layer rather than in your reconciliation code. Your systems receive a clean link between the open banking payment you created and the credit that arrived.
One payment model across the Baltics
The same two signals arrive in the same shape in every market on the platform, so a company running Latvia and its neighbouring markets writes the logic once and reuses it for any new market it opens.
- TwoIndependent signals per payment, not one
- Read-onlyAccount information service, on your own account
- LicensedBoth regulated services delivered by licensed institutions
- OnePayment model across any supported provider
Integration
Five steps, two of which are signals
- 1
Create the payment
One call on the open banking API with an amount, a currency, a reference and the destination C2B account.
- 2
The payer approves
Bank selection, then consent and authentication inside their own Latvian bank, exactly as for open banking payments elsewhere.
- 3
Signal one arrives
The provider status, normalised into one vocabulary whatever the provider called it in its own service.
- 4
Signal two arrives
The confirmed credit event, raised when the expected amount is on your own account. New payments never skip this step.
- 5
Your logic acts
Most businesses show progress on signal one and release value on signal two, in every market they run.
The two statuses
Accepted and credited, taken apart
The fullest version of this explanation on the site. Two signals, produced by different parties, describing different things, arriving at different moments. Understanding which one your product depends on is the single most consequential decision in an open banking integration, and it is worth settling before any new market goes live rather than after. The table underneath the two cards walks through the six situations a Latvian business actually meets, including the ones where the signals disagree.
- Signal one
Provider status
- Produced by
- Reported by the licensed PIS provider
- What it reports
- What the payer's bank said about the payment instruction after the customer approved it.
- What it means
- The instruction was accepted, rejected, or is still resolving. It describes the request, and it is the earliest useful information you can act on.
- What it does not mean
- It is not a statement that money has reached your account, and no provider claims otherwise.
- Signal two
Confirmed account credit
- Produced by
- Derived from a read-only account information service on your own C2B account
- What it reports
- That an amount matching the payment you created has been credited to the account your business holds.
- What it means
- The money is there. This is the fact a warehouse, a ledger or a customer balance should depend on.
- What it does not mean
- It arrives when the funds arrive, which may be after the payer's session has ended. It is never inferred from the provider status.
| Situation | Signal one | Signal two | What your system should do |
|---|---|---|---|
| Payment accepted, funds arrive | Accepted | Credited | Release. Both signals agree. |
| Payment accepted, funds do not arrive | Accepted | No credit event | Hold. This is exactly the case a single signal hides. |
| Funds arrive after the session ends | Accepted | Credited, later | Release when the credit event lands, not when the browser closed. |
| Reference altered by a bank | Accepted | Credited, matched by our layer | Release. Matching happens before the event reaches you. |
| Payment rejected at the bank | Rejected | No credit event | Fail cleanly. Nothing to reconcile afterwards. |
| Duplicate approval by the payer | Two accepted instructions | Credit events per amount received | Refund handling on facts, not on assumptions. |
- 2Independent signals produced per open banking payment
- 1Account ever read, and it is your own C2B account
- 0Facts about the payer's account used anywhere in this
Capabilities
Seven capabilities, including the one that is absent
| Capability | What it covers | Delivered by |
|---|---|---|
| Payment routing | To any supported licensed provider reaching the payer's Latvian bank | viaBanking |
| Payment initiation | A regulated service, on the user's payment consent | Licensed PIS provider |
| Authentication | Strong customer authentication inside the payer's bank | The payer's bank |
| Provider status | Normalised into one vocabulary across providers | viaBanking |
| Account credit confirmation | Read-only account information service on your own account | Licensed AIS provider, surfaced by viaBanking |
| Reference matching | Linking a credited amount back to the payment you created | viaBanking |
| Payer account data | Balances, statements and transaction history, out of scope | Not offered on any route |
Use cases
Who needs the second signal most
Financial platforms funding accounts
Where a customer balance must not appear before the money is genuinely on the company account, the second signal is the entire reason these open banking payments are worth integrating.
Marketplaces paying sellers onward
Seller balances updated from credited amounts rather than from acceptance messages, which keeps the platform from paying out against payments it has not received. Any new market on the platform behaves identically.
High value B2B invoicing
One large payment matters more than a hundred small ones, and knowing it arrived is worth more than knowing it was requested. This is the most common first use of open banking payments in the Latvian market.
Ecommerce shipping physical goods
Progress shown to the customer on the first signal, dispatch triggered on the second. The buyer sees a responsive checkout and the warehouse acts on money rather than on messages.
Subscription upgrades and renewals
New annual plans activated on the credit event, so an account is never upgraded against payments that did not complete. Card services keep handling the small recurring charges.
Any business reconciling by hand today
If somebody on your finance team opens a banking screen to match incoming payments, that is the work this service removes. Any supported provider on the route produces the same two signals.
Security and consent
Where the read-only permission starts and stops
The bank keeps the credentials
Authentication happens inside the Latvian bank the payer selected. No credential, code or device confirmation reaches viaBanking or your systems, whichever supported provider carried the payment.
The payment consent is single use
It names an amount, a beneficiary account and a reference, and it ends when the payment resolves. It grants nobody continuing access to the payer's account.
Read-only, and only your account
The account information service is scoped to the C2B account your business holds. It recognises an expected account credit and nothing else. It cannot manage the account, cannot move money and never reads the payer's account, their balances or their history.
FAQ
Six questions about the Latvian route
-
How does open banking work in Latvia?
Your system creates one payment, the payer approves it inside their Latvian bank, a licensed provider performs the initiation as a regulated service, and your systems then receive two signals: the provider status and, separately, a confirmed credit on your own C2B account. The second signal is what distinguishes this route from most open banking services in the market, and it is available on any supported provider.
-
Why is the provider confirmation not the final answer?
Because it describes the instruction rather than the money. A provider tells you what the payer's bank said when the payment was requested. Whether the amount reached the account your business reconciles against is a separate fact, produced by a read-only check on that account. Most of the time the two agree, and the cases where they do not are the expensive ones.
-
Which Latvian banks are reachable?
Reach comes from the licensed providers behind the route and covers the main Latvian banks, with a longer tail that varies by provider. We map your customers' actual institutions against live coverage before you build, and we do not publish a Latvian coverage figure the product has not confirmed.
-
Who is responsible for the regulated part?
Two different licensed institutions. A PIS provider performs the payment initiation and an AIS provider performs the read-only account information service behind the account credit confirmation. The accounts belong to banks and EMIs. viaBanking is a software company, holds neither authorisation and moves no funds.
-
How do we set up the provider and account combination?
The routing provider is configured with us and can be any supported licensed provider on the platform. The C2B account is opened by your company directly with an integrated bank or EMI. The two are independent choices, and neither one constrains the other or requires a change in your code.
-
Which businesses need this the most?
Anyone releasing something of value against open banking payments: goods, a customer balance, a seller payout or a new activated subscription. Businesses entering a new market usually feel it soonest, because a new market means new banks and new failure modes at the same time. Neighbouring markets run on the same integration and are covered on the Estonia and Lithuania pages, with the regional overview on the Europe page.
Find out what your current integration is actually telling you
Send us the payment statuses your systems act on today. We will show you which of them describe an instruction and which describe money, and what open banking in the Latvian market would look like with both signals in place. If you are already planning a new market alongside Latvia, the same open banking services cover it without new work.
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.