Demivolt logo

Launch Open Banking Integration in Lithuania Without Licensing Delays

Published 24 September 2026

Practical PSD2 roadmap for Lithuania: implement OAuth 2.0 and SCA, prevent 180 day consent failures, and use a regulated BaaS to cut months off launch.

Launch Open Banking Integration in Lithuania Without Licensing Delays

Open banking integration means connecting your platform to a bank’s regulated API as an Account Information Service Provider (AISP) or Payment Initiation Service Provider (PISP), or partnering with a licensed provider that already holds that authorization. The legal foundation is PSD2 and its Regulatory Technical Standards (RTS), enforced in Lithuania through the Bank of Lithuania’s API register. Your first technical move: build OAuth 2.0 authentication with Strong Customer Authentication (SCA) and a consent manager, or engage a regulated Banking-as-a-Service (BaaS) partner that has already solved this.

TL;DR:

  • Most Lithuanian banks build their APIs on the Berlin Group NextGenPSD2 framework with ISO 20022, but transaction status interpretation can differ, so explicit testing is essential.
  • Integrations require authorized AISP or PISP licenses, confirmed API documentation in the Bank of Lithuania register, and flows matching RTS Article 30 standards.
  • Build robust consent and SCA flows, schedule automatic re-authentication at least 10 days before the 180-day renewal window, and normalize data across banks for reconciliation.
  • Testing against sandbox environments must include consent expiration, interrupted SCA challenges, and transaction status edge cases to prevent production errors.
  • Using Demivolt’s regulated infrastructure allows fintechs to skip licensing delays, with ready-to-use accounts, SEPA and SWIFT transfers, and optional white-label BaaS solutions for faster market entry.
DemivoltBuild On Compliant Financial InfrastructureDemivolt provides regulated business banking and payment infrastructure for faster market entry, with accounts, SEPA and SWIFT transfers.Explore Demivolt

Table of Contents

What PSD2 and RTS Require From Every Integration

PSD2 obligates every Account Servicing Payment Service Provider (ASPSP), meaning any bank or payment institution holding customer accounts, to expose a secure interface so licensed AISPs and PISPs can reach account data or initiate payments once the account holder gives explicit consent. The RTS turns that principle into engineering requirements: common and secure communication standards, mandatory SCA on payment access, and dynamic linking that ties each authentication to a specific transaction amount and payee.

National regulators enforce these rules on the ground. In Lithuania, that means the Bank of Lithuania’s open banking register, which lists API interfaces for market participants including SEB, Swedbank, Luminor, Revolut, and Paysera. Before writing a line of integration code, confirm three things:

  • Your organization holds AISP/PISP authorization, or you’re partnering with an entity that does.
  • The target ASPSP’s interface appears in the Bank of Lithuania register with current technical documentation.
  • Your consent and authentication flows map directly to RTS Article 30 requirements, not a simplified approximation of them.

Global open banking transaction value hit $57 billion in 2023, with API call volume projected to reach 580 billion by 2027. The regulatory floor you’re building on is not a niche compliance exercise. It’s infrastructure that’s rapidly becoming default banking behavior across the EU.

Standards And API Models: Berlin Group, ISO 20022, And Interface Choices

Most Lithuanian ASPSPs build their APIs on the Berlin Group NextGenPSD2 framework, often paired with ISO 20022 message formats for payment initiation. That combination gives you predictable field structures, but it doesn’t guarantee identical behavior across banks. The EBA has flagged that inconsistent interpretation of transaction status codes across ASPSPs remains a real integration hazard, even among banks nominally using the same standard.

You’ll also choose between two interface philosophies:

  • Dedicated ASPSP interfaces, purpose-built for TPP access, typically faster and better documented.
  • PSU-facing interfaces reused for TPPs, which regulators permit under fallback conditions but which often carry inconsistent error handling.

Before committing to a bank’s API, test three things specifically: how it returns status codes for pending versus settled transactions, whether its message formats match the ISO 20022 schema it claims to support, and how it behaves under timeout or retry conditions.

Pro Tip: Build a status-code translation table for every ASPSP you connect to before writing business logic against it. Treating “pending” as identical across banks is one of the fastest ways to break reconciliation in production.

Building The Integration: A Step-By-Step Checklist

A production-ready open banking integration needs five architectural components working together: an API gateway that manages ASPSP connections, a consent manager, a token store, a webhook processor for real-time updates, and a reconciliation engine that reconciles what the bank reports against what your system expects.

Work through implementation in this order:

  1. Establish identity and auth. Implement OAuth 2.0 authorization code flow, install your eIDAS certificate for TPP identification, and confirm each ASPSP accepts your certificate chain before building further.
  2. Build the consent manager. Every consent object needs a creation timestamp, scope (balances, transactions, payment initiation), and an expiry clock. For AISP access, RTS permits reuse without fresh SCA for up to 180 days under specified conditions, so your system must track that window precisely, not approximately.
  3. Handle data mapping. Normalize transaction status fields, currency formats, and reference numbers across every connected ASPSP into one internal schema.
  4. Implement idempotency. Assign unique request identifiers to every payment initiation so a retried call after a timeout never triggers a duplicate transfer.
  5. Log everything. Consent grants, revocations, SCA challenges, and failed authentication attempts all need timestamped, auditable records.

Pro Tip: Schedule an automated trigger to force re-authentication 10 business days before a consent’s 180-day expiry. Waiting until expiry day to prompt the user creates access failures right when the customer needs the connection most.

SCA under RTS requires two of three elements: something the user knows (a PIN), something they have (a device or token), and something they are (biometrics). Payment initiation nearly always triggers SCA with dynamic linking to the exact amount and payee. Account information access carries more flexibility.

  • Low-risk AIS access can qualify for an SCA exemption, letting a returning user skip re-authentication on each visit.
  • Regulation (EU) 2022/2360 clarified how that exemption applies and aligned the renewal timeline: AISPs may access designated account data without fresh SCA for up to 180 days after the initial authentication.
  • Some implementations layer a shorter internal check, often around 90 days, as a risk control on top of the regulatory maximum, but the RTS ceiling itself is 180 days.

Every consent record needs a precise timestamp, a scheduled re-authentication date, and a mechanism to force re-auth early if you detect anomalous access patterns. Treat the 180-day window as a hard compliance boundary, not a soft guideline your engineering team rounds up from memory.

Testing And Sandbox Validation Before You Go Live

Every ASPSP listed in the Bank of Lithuania register publishes sandbox credentials and test endpoints. Use them before touching production traffic.

  1. Run full AIS and PIS flows against sandbox data, including successful and rejected consent grants.
  2. Simulate an expired consent request and confirm your system prompts re-authentication rather than failing silently.
  3. Interrupt an SCA challenge midway and verify your app recovers gracefully instead of leaving a stuck session.
  4. Test transaction-status mapping against edge cases: pending-to-failed transitions, partial settlements, and reversed payments.
  5. Confirm reconciliation logic catches mismatches between what the ASPSP reports and what your ledger expects.

Once in production, monitor uptime against each ASPSP’s published SLA and build contingency routing for banks that experience outages, since a single failed connection shouldn’t take down your entire service.

Operational Risks That Break Integrations In Production

Consent-tracking errors cause more production incidents than API downtime. A missed 180-day renewal, a misread scope, or a silently expired token all create the same result: a customer locked out of a service they thought was connected. Inconsistent transaction-status handling across ASPSPs is the second most common failure point, as the EBA’s own guidance confirms.

  • Run partner due diligence before any white-label or reseller relationship goes live, not after.
  • Keep public-facing disclosures accurate about which entity holds the license and which is the technical provider. Bank of Lithuania supervisory guidance explicitly expects this clarity.
  • Build idempotent retry logic for every payment call, and version your internal API so ASPSP-side changes don’t break downstream consumers without warning.

Pro Tip: A technical service provider (TSP) can operate under a licensed TPP’s authorization and present that TPP’s eIDAS certificate, but the licensed TPP still carries legal responsibility for the connection. Get that liability allocation in writing before go-live, not after an incident.

The industry shift from screen scraping toward token-based OAuth connections has measurably improved both security and user experience for account verification and payment initiation, and it’s worth building toward that model even where a fallback interface is still technically permitted.

Where Demivolt Fits Your Integration Checklist

Every checklist item above, regulated infrastructure, SEPA and SWIFT rails, consent-aware onboarding, and API-ready account structures, maps directly to what Demivolt already operates as licensed infrastructure. Instead of building AISP or PISP authorization from scratch, your team can connect to Demivolt’s business accounts with dedicated IBANs already segregated under EU safeguarding rules.

For payment flows specifically, Demivolt’s payments infrastructure handles SEPA and SWIFT rails without requiring you to negotiate individual ASPSP connections. Fintechs building a broader product can use Demivolt’s BaaS platform to skip months of licensing and sandbox negotiation entirely, cutting the governance burden your compliance team would otherwise own alone.

Priority Actions For The First 90 Days

Sequence matters more than speed here. Build the consent manager and SCA flows first. Run full sandbox validation second, including expired-consent and interrupted-auth cases. Only after both pass should engineering and compliance jointly sign off on a production partnership agreement. Split the work cleanly: engineering owns auth and data mapping, product owns consent UX, and compliance owns disclosure language and audit trail.

For teams that want to skip the licensing timeline entirely, Demivolt’s partner and white-label models are worth a look before you commit engineering headcount to a build-it-yourself path.

— dd

A Faster Path To A Compliant Integration

Demivolt is the alternative to building AISP/PISP authorization from the ground up: instead of spending months on licensing, sandbox negotiation, and consent-infrastructure engineering, you connect to infrastructure that’s already regulated and already live.

Demivolt

A regulated business account provider’s offerings may include dedicated IBANs and segregated client funds, with payments infrastructure that handles SEPA and SWIFT transfers without requiring individual ASPSP connections for each corridor. Card programme infrastructure and role-based user management extend naturally on top of the same account structure, so a payments feature and an expense-card feature don’t require two separate vendor relationships. Fintechs and platforms building at scale can use Demivolt’s white-label BaaS to launch under existing regulatory infrastructure rather than pursuing their own authorization first. Advisors and consultants working with multiple clients can also explore the reseller program for recurring commission on referred accounts.

If your 90-day roadmap includes a production partnership decision, request account details from Demivolt and get a working IBAN structure in place before your sandbox testing phase ends.

A Faster Path To A Compliant Integration — overview diagram

This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.

Sources

FAQ

What Is Open Banking Integration Under PSD2?

It’s the technical and legal process of connecting your platform to a bank’s regulated API, either as a licensed AISP/PISP or through a partner that holds that license, following PSD2 and RTS requirements for consent and authentication. The Bank of Lithuania’s API register lists which local ASPSPs currently support this.

AISPs can access designated account data without requiring fresh SCA for up to 180 days after the initial authentication, under conditions set by Regulation (EU) 2022/2360. Best practice is to trigger re-authentication prompts roughly 10 business days before that window closes.

Do I Need My Own AISP/PISP License To Integrate?

No. You can either obtain your own authorization or connect through a regulated partner, such as a licensed BaaS provider, that already holds the license and infrastructure. This route typically cuts months off time-to-production compared to seeking your own authorization from scratch.

Which Technical Standard Should I Build Against?

Most Lithuanian ASPSPs use the Berlin Group NextGenPSD2 framework alongside ISO 20022 message formats, but interpretation of status codes still varies between banks, so test transaction-status mapping explicitly rather than assuming uniform behavior.

What Does Demivolt Charge For Business Accounts?

Demivolt’s account opening, verification, and monthly maintenance carry no published fee, while SEPA outgoing transfers cost €0.40 per transfer and SWIFT outgoing transfers cost €30.00. Full current pricing for other services is available directly on Demivolt’s site.

Susiję su šiuo straipsniu

Verslo sąskaitos

Verslo sąskaitos, asmeniniai IBAN numeriai, mokėjimai, kortelės ir valiuta įmonėms, dirbančioms tiesiogiai su Demivolt.

Learn more