Eika Mobilbank: one app, dozens of Eika banks, one account feed

One login to Eika Mobilbank can front any of dozens of independent Norwegian savings banks — Agder Sparebank, Haugesund Sparebank, Skue Sparebank and the rest of the Eika alliance — and that shared-platform shape is the first thing any integration against it has to deal with. Eika's own mobile-bank page describes the app as serving 53 banks; its Play Store listing names around forty member banks. Either way you are not integrating one bank. You are integrating an alliance that presents as a single app. The data behind it is ordinary retail- and business-banking data — balances, transactions, payments, cards, loans, savings, insurance — and in Norway it is reachable through a regulated, consent-based channel rather than anything exotic.

Here is the bottom line. Most of what an integrator wants — a clean, normalized account-and-transaction feed across whichever alliance bank a customer belongs to — comes through the regulated AIS channel, and that is the part we build first because it carries a legal stability contract and produces clean consent records. The few surfaces that channel never exposes (the card-PIN view, the digital card, the "how much until payday" forecast) we add by authorized analysis of the app's own traffic, scoped only when you actually need them. That split is the whole shape of an Eika build.

Account data behind the login

These are the surfaces the app actually shows, named the way it names them, with where each one originates and what an integrator typically does with it.

Reaching the data under consent

Which routes apply depends on the surfaces you need; here are the ones that genuinely do for this app. We arrange the access for each with you during onboarding — a sponsor sandbox or a consenting customer account — so none of this is something you have to clear before we start.

Regulated AIS over Berlin Group XS2A

Norwegian banks expose PSD2 access interfaces under the EEA-adopted directive, built to the Berlin Group NextGenPSD2 (XS2A) standard. This is the durable, stable channel: it reaches accounts, balances and booked plus pending transactions, with payment initiation available where you also need PIS. Production runs under an AISP registration with Finanstilsynet or through a passported aggregator; we wire up whichever you prefer. Effort is mostly onboarding rather than engineering, and the contract is regulated, so it does not drift between app releases.

Authorized protocol analysis of the app traffic

The card-PIN view, the digital card, the payday forecast and the consolidated insurance/loans/savings panels are app-only. They never appear on the XS2A interface. Where you need them, we analyse the app's own authenticated traffic under your authorization, document the calls, and rebuild them as a clean interface. This route tracks the app's release cadence, so we plan re-checks into maintenance.

User-consented credential operation

For narrow asks, operating inside a consenting account to read exactly what that user sees is sometimes the lightest path — useful when AIS scope is too coarse for a specific screen. It is the most release-sensitive of the three and we treat it as a complement, not a foundation.

For most Eika asks the regulated AIS channel is the one to build the product on, because it is the only route here with a legal durability guarantee and audited consent records; we layer protocol analysis on top only for the in-app screens PSD2 was never designed to carry. We tell you plainly which surfaces fall on which side before any code is written.

What the read flow looks like

A first sketch of the consent-and-read path against one alliance bank's ASPSP, in the Berlin Group shape. Field names are confirmed against the specific bank's base during the build; the values below are illustrative.

# Illustrative — Berlin Group NextGenPSD2 (XS2A) shape.
# {aspsp_base} resolves per alliance bank (Aurskog, Haugesund, ...).

POST {aspsp_base}/v1/consents
  X-Request-ID: <uuid>
  PSU-IP-Address: <psu_ip>
  body: { "access": { "balances": [...], "transactions": [...] },
          "recurringIndicator": true,
          "validUntil": "2026-09-13",
          "frequencyPerDay": 4 }
  -> 201 { "consentId": "c-7f3...",
           "_links": { "scaRedirect": "<BankID flow>" } }

# PSU completes BankID strong authentication, then:
GET {aspsp_base}/v1/accounts/{accountId}/transactions
    ?dateFrom=2026-01-01&bookingStatus=both
  Consent-ID: c-7f3...
  -> 200 { "transactions": {
             "booked":  [ { "bookingDate":"2026-06-10",
                            "transactionAmount":{"amount":"-220.00","currency":"NOK"},
                            "remittanceInformationUnstructured":"..." } ],
             "pending": [ ... ] },
           "_links": { "next": "...page=2" } }   # follow until no next

# Error handling worth wiring from day one:
#   429  -> back off; XS2A frequencyPerDay caps unattended polls
#   401 + CONSENT_EXPIRED -> re-trigger BankID SCA, refresh consentId
      

What lands in your repository

Everything below is tied to Eika's real surfaces, not a generic kit:

• An OpenAPI/Swagger specification for the normalized feed — accounts, balances and transactions endpoints, with the per-bank routing parameter modelled in.
• A protocol and auth-flow report covering the BankID SCA redirect, the Berlin Group consent lifecycle (creation, status, expiry, renewal) and token handling.
• Runnable source in Python or Node.js for consent creation, account listing and paginated transaction pulls with bookingStatus handling.
• Automated tests run against a sandbox or a consenting account, including the consent-expiry and re-authentication path.
• Interface documentation, plus compliance and data-retention guidance written for a PSD2/AIS context.

One schema across the alliance

Because the same app fronts many banks, the value is in normalizing them. The handover feed tags every record with which institution and which profile it came from, so a consumer of the feed never has to care that Aurskog Sparebank and Haugesund Sparebank are distinct ASPSPs.

{
  "institution": "no.eika:aurskog-sparebank",   // resolved per consent
  "profile":     "personal",                     // personal | business
  "account": { "iban": "NO93...", "currency": "NOK", "type": "current" },
  "balance": { "amount": "12340.55", "type": "interimAvailable",
               "asOf": "2026-06-15T08:00:00Z" },
  "transaction": { "bookingDate": "2026-06-10", "amount": "-220.00",
                   "remittance": "Kiwi 312 Storgata",
                   "status": "booked" }
}
      

PSD2, BankID and the consent model

Norway implements PSD2 as an EEA member, transposed through the Finansavtaleloven, with Finanstilsynet as supervisor. Account information services register with Finanstilsynet rather than holding a full payment-institution authorization, and registrations passported in from elsewhere in the EEA are recognised. Strong customer authentication runs through BankID, the national scheme Norwegian banks already use for login.

Consent is scoped to what the customer grants — typically accounts, balances and transactions — and a recurring AIS consent carries an explicit validUntil and a per-day frequency cap, so the design has to renew rather than assume an open feed. Consent is revocable at any time. We operate authorized, documented and user-consented access only: every call is logged against a consent record, data is minimized to what the use case needs, and we sign an NDA where the work touches your customers. The business-versus-personal split matters here too, because the two relationships consent separately.

What this build has to account for

The parts that take real engineering judgment on this app, all handled on our side:

• Multi-tenant alliance routing. Dozens of banks share one app but each is a separate institution with its own bank code and XS2A base. We map the per-bank routing so a consent for an Odal Sparebank customer reaches the right ASPSP, and we normalize every bank's response into one schema regardless of which alliance member the user belongs to.
• Personal and business in one shell. The app toggles between a private relationship and a business one, and the two carry different account sets and authorization scopes. We model the profile dimension so a business consent never silently returns personal accounts, and the reverse.
• Consent-refresh cadence. AIS consent expires and needs a fresh BankID step-up on a regulated schedule. We design the sync around that window so the feed re-authenticates on time instead of going quietly stale.
• App-only surfaces drift. Anything reached by protocol analysis — the card view, the payday forecast — moves with app releases. We keep a release-watch step in maintenance so a front-end change does not break the capture without anyone noticing.

Screens we worked from

The published store screenshots, used to map which surfaces sit behind the login. Select one to enlarge.

Other Norwegian banking apps in the same frame

If you are unifying more than one Norwegian source, these sit alongside Eika Mobilbank in the same market and consent regime:

• Vipps — the dominant mobile-payment and P2P app; holds payment and linked-card history. Eika Gruppen is among its part-owners.
• DNB Mobilbank — the app of Norway's largest bank; accounts, cards and payments behind BankID.
• SpareBank 1 Mobilbank — the other large savings-bank alliance app, with a similar account, transaction and savings spread.
• Nordea Mobile — the Norwegian build of the pan-Nordic bank; accounts, payments and cards.
• Sbanken — a digital-first Norwegian bank (now within DNB) with strong personal-finance views.
• Bank Norwegian — a consumer-finance app from NOBA Bank Group; credit cards, savings and loans.
• Bulder Bank — a mobile-first bank from Sparebanken Vest, centred on accounts and home-loan data.
• Handelsbanken — accounts, payments and cards for the Norwegian market, also behind BankID.

This is ecosystem context, not a ranking. Each one holds account-level data a unified integration would normalize the same way Eika's is normalized.

Questions integrators ask about Eika

We bank with several different Eika banks. Does one integration cover all of them?

Mostly, yes. The app fronts dozens of independent savings banks on one shared platform, so we route each consent to the right bank under the hood and hand you back a single normalized feed. Consent is still granted per customer at each bank, and a business relationship is consented separately from a personal one.

Can you reach the card PIN view and the 'left until payday' forecast, or only statements?

Balances, accounts and transactions come through the regulated AIS channel cleanly. The card-PIN view, the digital card and the payday forecast are in-app-only surfaces that the PSD2 interface never carries, so we cover those by authorized analysis of the app's own traffic when they are in scope.

Which Norwegian regulator and technical standard does this fall under?

Finanstilsynet supervises. Access rides PSD2 as adopted under the EEA agreement and Norway's Finansavtaleloven, over Berlin Group NextGenPSD2 (XS2A) interfaces, with BankID handling strong customer authentication.

Do we need our own AISP registration before you can build the Eika feed?

No. We build against a sandbox or a consenting account, and production can run either under your own AISP registration with Finanstilsynet or through a passported aggregator. We settle which of those fits during onboarding, along with access and compliance.

What we checked

This mapping was put together from the app's own store and bank-group descriptions and Norway's open-banking record, read in June 2026: the Eika Gruppen alliance overview, the app's mobile-bank page, the Norwegian open-banking regulatory record, and Finanstilsynet's licensing pages. Counts and identifiers here (the number of alliance banks, the package ID) are reported as their sources state them and not asserted independently.

• Eika Gruppen — alliance overview
• Eika Mobilbank — the bank-group's own app page
• Norway open-banking record — PSD2, Berlin Group NextGenPSD2 status
• Finanstilsynet — banking and finance licensing

OpenBanking Studio · integration-desk mapping, 15 June 2026.

If you want this built, the engagement is short and the pricing is plain. We deliver runnable source plus the spec, tests and interface docs for around a one-to-two-week cycle, from $300, and you pay after delivery once it works the way you need; or you skip the build entirely and call our hosted endpoints, paying only per call with nothing upfront. Tell us the bank or banks in scope and what you want out of the Eika feed and we will scope it — start the conversation here.