Reaching سلفة's borrower ledger through an authorized integration

The short version

Borrow SAR 20,000 over 18 months in سلفة and the app holds a fixed commitment against you: processing fee SAR 200, VAT on that fee SAR 30, total repayment SAR 29,990, an APR in the example of 75.32% and a monthly installment of SAR 1,666.11 — all per the loan example سلفة publishes on its own pricing page. That single screen is structured per-user financial state, and there are several more like it: the application, the accepted contract, the repayment ledger, and on the other side of the product a financing marketplace where individuals fund other individuals.

سلفة is a SAMA-licensed consumer microfinance company that ran through the Saudi Central Bank's Regulatory Sandbox before licensing, per SAMA's own announcements. Two facts shape every integration here. The lender's contract and profit-rate data live in سلفة's systems, not a bank's, so they come through authorized interface integration of the app. The money movement — the disbursement credit and the monthly debits — lands in the borrower's bank account, where a regulated SAMA Open Banking AIS consent can read it. We build both and join them on one loan reference.

What سلفة holds on each borrower and investor

Every row below is a real surface of the product as the app and its pricing page describe it, not a generic feed list.

Three routes in, and which one carries the weight

Authorized interface integration of the سلفة app

Under the customer's authorization, we analyze the app's own client-server traffic and rebuild the calls that return the application, contract, cost-of-credit breakdown, installment schedule and investor positions. This is the route that actually reaches سلفة's loan ledger, because that data is the lender's, not a bank's. Effort is moderate; durability is tied to the app's front end, which we account for in maintenance. Access and the consenting test account are arranged with you during onboarding.

Regulated AIS under the SAMA Open Banking Framework

SAMA issued the first release of its Open Banking Framework covering Account Information Services in November 2022 and a second release covering Payment Initiation in September 2024, per Open Banking Expo and SAMA. An AIS consent reads the borrower's bank account: the سلفة disbursement credit and each monthly installment debit as they settle. It is consent-bound, expiry-aware and durable, but it does not expose سلفة's contract or profit-rate fields. We use it for the money-movement half of the picture and the studio handles the participant onboarding with you.

User-consented session export

Where a borrower or investor consents, we operate an authorized session to export their own statements and schedule directly. Lowest effort, narrowest scope, useful as a fallback or for one-off reconciliation.

For most buyers the workable shape is interface integration as the backbone for everything سلفة itself computes, with a SAMA AIS consent layered on for the bank-side cash movement, joined on a shared loan reference. The session route is there when only a single consenting account's history is needed. We will say plainly during scoping which of the three your use case actually needs rather than selling all of them.

The build you get

Deliverables are tied to سلفة's real surfaces, not a generic kit:

• An OpenAPI/Swagger specification covering loan application, contract, cost-of-credit, installment schedule, disbursement and investor-position objects.
• A protocol and auth-flow report: how the session is established, how the token is obtained and refreshed, and how the app paginates the schedule and marketplace lists.
• Runnable source for the key endpoints in Python and Node.js — pull a borrower's contract and schedule, pull an investor's positions, reconcile against the AIS bank feed.
• Automated tests covering the cost-of-credit math (fee + VAT + profit → APR and installment) so a regression in mapping is caught.
• Interface documentation a developer can hand to a teammate, plus data-retention and consent-logging guidance scoped to PDPL and SAMA expectations.

A look at the installment-schedule call

Illustrative shape of the schedule lookup against an authorized session — exact field names are confirmed during the build, not guessed here.

GET /api/v1/loans/{loanId}/schedule
Authorization: Bearer <session_token>        # obtained via the app's
Accept-Language: ar                              # auth flow; refreshed on 401

200 OK
{
  "loanId": "LN-… (opaque)",
  "principal": 20000.00, "currency": "SAR",
  "tenureMonths": 18,
  "cost": {
    "processingFee": 200.00,                     # 1% per pricing page
    "vatOnFee": 30.00,                           # 15% on the fee
    "profit": 9990.00,
    "apr": 75.32,                                # example loan, not a constant
    "totalRepayment": 29990.00
  },
  "installments": [
    {"seq": 1, "dueDate": "2026-06-01",
     "amount": 1666.11, "status": "DUE"},
    {"seq": 2, "dueDate": "2026-07-01",
     "amount": 1666.11, "status": "SCHEDULED"}
    /* … through seq 18 … */
  ]
}

# 401 -> re-run auth flow, retry once
# 409 consent_expired -> trigger AIS re-consent on the bank-side join

The cost block is captured as سلفة derives it, never recomputed by us, so a downstream consumer sees the borrower's actual contracted figures.

Consent, SAMA and the rules this sits under

سلفة operates under a Saudi Central Bank consumer microfinance licence and went through SAMA's Regulatory Sandbox, per SAMA's licensing and sandbox announcements; mid-2024 sandbox notices also reference peer-to-peer financing activity for the company. The bank-side route runs on the SAMA Open Banking Framework — AIS from the November 2022 first release. Consumer data under that framework is governed by Saudi Arabia's Personal Data Protection Law: access requires explicit, informed and revocable consent, and a consent has a bounded lifetime.

How we work follows from that: authorized or user-consented access only, every consent and pull logged with its scope and timestamp, data minimized to the fields a use case needs, and an NDA where the engagement calls for one. Consent expiry and revocation are designed into the sync rather than discovered when a feed goes quiet.

Engineering realities we plan around

Two specifics on سلفة shape the build, and we handle both on our side:

• Two ledgers, one loan. The contract, profit rate and schedule come from the app; the disbursement credit and monthly debits come from the SAMA AIS bank consent. We key both to a shared loan reference so a reconciled timeline is one object, not two feeds a consumer has to align by hand.
• Sharia-compliant pricing, labelled correctly. Cost of credit here is processing fee plus VAT plus profit, not conventional interest. We map سلفة's fee, VAT and APR fields into a normalized cost-of-credit schema so a downstream system never mis-labels a Murabaha-style fee as interest.
• Consent window. The AIS consent expires under PDPL timing; the sync is designed around the re-consent point so the bank-side join does not silently lapse mid-cycle.
• Front-end churn. The app ships updates regularly (per its Play Store listing); maintenance includes a scheduled check that re-validates the captured flows whenever سلفة changes its client.

Where integrators take this

• A lending-marketplace aggregator pulls a consenting borrower's سلفة contract and schedule to show total indebtedness across Saudi lenders before offering a refinance.
• A personal-finance app reconciles the سلفة disbursement and each monthly installment debit against the user's bank feed, so the loan shows correctly in their cash-flow view.
• An investor dashboard aggregates a marketplace lender's سلفة positions and monthly returns alongside other holdings for one portfolio number.

What was checked, and against what

This was put together from the app's Play Store listing and its own loan-pricing page for the amounts, fees, VAT, APR and tenure; from an Open Banking Expo report and SAMA for the AIS and PIS release timing; and from SAMA's consumer-microfinance licensing notice for سلفة's regulatory status. Figures here are quoted as those sources state them and are not independently recomputed.

• سلفة on Google Play (com.sulfah)
• سلفة loan-pricing page (fees, VAT, APR example)
• SAMA second release of the Open Banking Framework (PIS)
• SAMA licensing of a fintech consumer-microfinance company

Compiled by the OpenBanking Studio integration desk — reviewed 2026-05-16.

Other Saudi financing apps in the same data picture

Same category, similar server-side state — useful context when a buyer wants one integration spanning several Saudi lenders. Named neutrally, no ranking.

• Tamam — Sharia-compliant micro and personal finance, fully digital application to disbursement; holds comparable loan and repayment records.
• Quara Finance (Naqdi) — digital personal financing; per-user loan and installment data behind an account.
• Nayifat — Islamic financing products for individuals and businesses; contracts and repayment schedules server-side.
• Arib — a personal-finance marketplace partnering with many licensed providers; aggregated offer and application data.
• Tamweelcom — instant personal lending with fast disbursement; loan status and repayment state per user.
• Mora Finance — a Saudi consumer-financing competitor named in market comparisons; account-bound loan data.
• meem — digital banking with personal finance; account and financing records behind login.
• Taajeer Finance — emergency cash and personal financing; per-user loan and installment ledger.
• Wadaie — the savings fintech SAMA permitted alongside سلفة; a related regulated data source in the same ecosystem.

Screens from the app

Public Play Store screenshots, for interface reference. Tap to enlarge.

Questions integrators ask about سلفة

Does Open Banking AIS reach سلفة's loan ledger, or only the linked bank account?

SAMA Open Banking AIS reaches the borrower's bank account — the disbursement credit and the monthly installment debits as they hit that account. It does not surface سلفة's own contract, profit-rate breakdown or schedule, because those live in سلفة's systems, not a bank's. To get the loan ledger itself we use authorized interface integration of the app under the customer's authorization, then stitch the two on a shared loan reference.

سلفة is Sharia-compliant and SAMA-licensed — does that change how the integration is built?

Yes, in the data model. The cost of credit is expressed as a processing fee plus VAT plus profit, not conventional interest, so we map سلفة's fee, VAT and APR fields into a normalized cost-of-credit schema and label the components correctly rather than calling a Murabaha-style fee interest. The SAMA licence also means the access path stays inside an authorized, logged, consent-based design.

Can the investor side of سلفة — the financing marketplace and monthly returns — be integrated too, not just borrowing?

Yes. سلفة also runs a financing marketplace where individuals fund other individuals from small amounts and receive monthly returns. That investor view — positions, expected returns, repayment status of funded loans — is server-side per-account data and is reachable through the same authorized session route as the borrower ledger; we treat it as a second object set in the same spec.

How is the APR and fee breakdown captured — exactly as سلفة computes it?

Exactly as the app computes it. سلفة's published example — SAR 20,000 over 18 months, processing fee SAR 200, VAT SAR 30, total repayment SAR 29,990 — is the shape we capture: principal, tenure, processing fee, VAT on fee, profit, APR and the resulting installment, per loan, as derived values rather than recomputed by us, so a downstream consumer sees the borrower's actual contracted cost.

Engaging on this

Tell us the app — سلفة — and what you need out of its data; the access path, the consenting test account and any authorizations are arranged with you as part of the work, not asked of you before we start. Two ways to engage. We deliver the runnable source plus its OpenAPI spec, protocol report, automated tests and interface documentation, and you pay from $300 only after delivery, once it runs as described. Or we host the endpoints and you pay per call, nothing upfront. Either path runs on a one-to-two-week cycle. Start at /contact.html.