Reaching slice's savings, UPI and lending records after its bank merger

In October 2024 slice completed its merger with North East Small Finance Bank, and that single fact reshapes how a third party reaches its data. What used to be a prepaid-credit fintech is now a regulated small finance bank holding savings balances, fixed deposits and loan accounts on its own books. Deposit and credit records held by a licensed bank in India are exactly the surfaces the RBI's Account Aggregator network was built to share — with the account holder's consent. So the integration question for slice is not whether the data can be reached cleanly, but which slice of it you want and at what granularity.

The short version: for the money-movement and balance data, the Account Aggregator path is the durable one and we would build on it first. For the things slice computes itself — the merchant-level spend categories, reward and cashback state on the UPI credit card, the in-app FD comparison view — there is no AA schema, so those come through an authorized session against the app's own interface. Most real briefs want both, stitched into one normalized feed.

What slice actually holds

Mapped to where each surface originates inside the product, and what an integrator typically does with it.

Routes that genuinely apply

Account Aggregator consent (regulated AIS)

Because slice is a licensed bank, its deposit and loan data is reachable as a Financial Information Provider on the AA network. A consenting user authorizes an RBI-licensed Account Aggregator, the data moves end-to-end encrypted from slice to the requesting party, and the AA never reads it. This is the strongest path: the schema is standardized, consent is logged and revocable, and it does not break when slice changes its app screens. We register the FIU side or work through a licensed AA partner, and arrange that during onboarding with you.

Authorized app-interface integration

The product-layer surfaces — categorized spend, cashback and reward state, the FD comparison view, card-statement formatting — are computed by slice and not exposed through AA. We reach those by analyzing the app's own authenticated traffic under your authorization: the login and token-refresh chain, then the specific calls that return statements and spend tags. Faster to a working prototype, but it tracks the app's front end, so we budget for re-validation.

User-consented credential access

Where a consenting account holder wants their own data exported and AA does not yet carry a particular surface, we run the interface integration against that account under explicit consent and a clear data-minimization scope. Useful as a bridge for one-off exports or for surfaces still being onboarded to AA.

For a production build that needs to stay reliable, the Account Aggregator path carries the balances, deposits and loan records, and the authorized interface fills in the spend and rewards layer slice computes on top. That split is what we would actually recommend for slice, because it puts the durable money data on regulated rails and only uses the more maintenance-heavy path where there is no alternative.

What lands in your repo

• An OpenAPI 3 specification covering the slice surfaces in scope — deposit ledger, FD list, loan and EMI records, UPI/payment history, and the spend-category endpoint where it is reached through the interface path.
• A protocol and auth-flow report: the AA consent handshake and FI-data fetch on one side, and on the other the app's token acquisition, refresh cadence, and the headers and error codes its statement calls return.
• Runnable source for the key endpoints in Python or Node.js — consent request, data fetch, pagination, and a normalizer that maps slice records into a single account/transaction schema.
• Automated tests against recorded fixtures, plus a contract check that flags when a slice response shape drifts.
• Interface documentation and data-retention guidance written for India's consent rules, so your team knows what may be stored and for how long.

How a consent-plus-fetch looks

Illustrative, confirmed against the surface during the build — an AA consent request scoped to slice's deposit and loan data, then a fetch that returns the bank-side records, with the interface path used only for the categorized-spend overlay.

# 1. Request consent via a licensed Account Aggregator (FIP = slice SFB)
POST /aa/consents
{
  "fipId": "SLICE-SFB",
  "consentTypes": ["TRANSACTIONS", "SUMMARY", "PROFILE"],
  "fiTypes": ["DEPOSIT", "TERM_DEPOSIT", "RECURRING_DEPOSIT", "LOAN"],
  "purpose": { "code": "101", "text": "account aggregation" },
  "frequency": { "unit": "MONTH", "value": 1 },
  "dataLife": { "unit": "MONTH", "value": 1 }   # consent is time-bound + revocable
}
-> 200 { "consentHandle": "c-9f2a...", "status": "PENDING" }   # user approves in-app

# 2. After approval, fetch FI data (end-to-end encrypted; AA stays data-blind)
POST /aa/fi/fetch  { "consentId": "...", "sessionId": "..." }
-> { "DEPOSIT":  [ { "maskedAccNumber": "XXXX1234", "balance": "...",
                     "dailyInterestCredit": "...", "txns": [ ... ] } ],
     "LOAN":     [ { "principalOutstanding": "...", "emiSchedule": [ ... ] } ] }

# 3. Product-layer overlay NOT in the AA schema -> authorized interface path
GET /v1/spend/categories?from=2026-05-01   Authorization: Bearer <session>
-> { "buckets": [ { "tag": "food", "amount": "...", "txnIds": [ ... ] } ] }

# Errors we handle: AA consent EXPIRED/REVOKED -> re-consent;
# interface 401 -> token refresh; 429 -> backoff with jitter.
      

Consent and the RBI rulebook

For slice the governing regime is the RBI's NBFC-Account Aggregator Directions, the framework that came into commercial operation in 2021 and is operated technically through Sahamati. No financial record leaves slice without the account holder's explicit consent, the consent artefact names the purpose and the exact data types, it expires on a set date, and the user can revoke it at any time. We build to that: consent state is checked before every fetch, consent and access events are logged, data we hold is minimized to what the stated purpose needs, and we work under an NDA where a client requires it. On the credit side, slice now reports its lending to bureaus such as CIBIL as ordinary credit accounts since becoming a bank — we read the borrower's own loan records under consent and do not touch bureau rails. This is how the studio operates as a matter of course, not a hurdle placed in front of the work.

Engineering notes specific to slice

Two things shape a slice build, and we account for both rather than hand them to you as conditions.

• Two identities, one app. slice carries a fintech history and a bank present tense. Deposit and loan data belongs to the bank entity and routes through AA as a Financial Information Provider; the card rewards, cashback and spend-tagging are app-side product logic. We map which surface belongs to which side so a fetch does not silently miss the half that AA cannot carry.
• Consent windows that quietly lapse. AA consent is time-bound by design, so a sync built without a refresh path stops returning data when the window closes. We design the schedule around the consent's stated data-life and wire re-consent into the flow before it expires, so the feed does not go dark mid-month.
• Front-end drift on the interface path. The spend-category and card-statement surfaces are reached through the app's own interface, which slice updates on its own cadence. We build a re-validation pass into maintenance so a screen change is caught by the contract tests rather than by your users.

Access to a sandbox or a consenting account is arranged with you during onboarding; the build runs against whichever fits the route.

Interface evidence

Store screenshots of the surfaces referenced above. Click to enlarge.

Where slice sits among comparable apps

Same-category Indian apps a unified integration tends to touch alongside slice. Listed for ecosystem context, not ranked.

• OneCard — a metal credit card run with partner banks; holds card statements, limits and reward state behind an authenticated account.
• Jupiter — a neobank on Federal/CSB rails offering a UPI RuPay credit card; holds savings, card and cashback data.
• CRED — credit-card management and bill payments; holds linked-card statements, due dates and reward points.
• Uni Card — a credit product with gold-denominated rewards; holds statements and repayment records.
• Fi Money — a Federal Bank neobank; holds savings balances, transactions and goal-based pots.
• BharatPe PostPe — a buy-now-pay-later line; holds credit-line balances and merchant repayment history.
• Stashfin — a credit-line and personal-loan app; holds loan accounts and EMI schedules.
• OneScore — credit-score tracking; holds bureau pulls and score history.

Most of these are AA-reachable for their bank-held data and interface-reachable for the analytics they compute in-app — the same two-path shape we apply to slice.

Sources and how this was put together

Checked in June 2026 against the merger announcement, the bank's own listings, and the RBI Account Aggregator references. Primary sources:

• slice & NESFB merger completion release
• Slice Small Finance Bank — background and timeline
• Sahamati — Account Aggregators in India
• Dept. of Financial Services — Account Aggregator framework

Reviewed 28 June 2026 by the OpenBanking Studio integration desk.

Questions an integrator asks about slice

slice is now a small finance bank — does that change how its data is reached?

It changes it for the better. After the October 2024 merger with North East Small Finance Bank, slice holds deposits and loans as a regulated bank, which means its savings, FD and lending records sit behind India's Account Aggregator consent network as a Financial Information Provider. That gives a clean, consent-based path to the account-level data rather than only screen-level scraping.

Can UPI transaction history and spend categories come through the Account Aggregator route?

Bank-side transaction records tied to the savings account flow through the AA deposit schema. The merchant-level spend categories slice computes in-app (food, transport, bills, shopping) are a product feature layered on top, so we reach those through an authorized session against the app's own interface when a client needs the categorized view rather than raw debits and credits.

Which regulator and scheme govern this for slice?

The Reserve Bank of India. The deposit and credit data sits under the RBI NBFC-Account Aggregator Directions, with consent orchestrated by an RBI-licensed AA and the technical standards maintained by Sahamati. Consent is explicit, time-bound, purpose-bound and revocable, and the AA itself is data-blind.

Does slice report to credit bureaus, and is that reachable?

Since the bank conversion, slice credit lines report to bureaus like CIBIL as regular credit accounts. We do not pull bureau data through slice; for a borrower-facing build we reach the loan and repayment records held in the slice account directly, under the user's consent, and leave bureau reporting to the bureau's own rails.

If a slice integration is on your roadmap, send the app name and what you want out of its data and we will scope it. Source-code delivery starts at $300: you receive the runnable API source, the OpenAPI spec, tests and interface docs, and pay only once the delivery is in hand and you are satisfied. Prefer not to host it yourself — call our endpoints on a pay-per-call hosted API instead, with no upfront fee. The build cycle is one to two weeks either way. Start the conversation at /contact.html.