GoodScore keeps a full Experian and CRIF credit report behind one login

Two bureau feeds land in one place inside GoodScore. The app pulls a consumer's report from Experian and from CRIF High Mark — two of the four credit information companies RBI licenses — and renders a score plus an account-by-account breakdown of every active and closed credit line. For anyone who wants that report inside their own system rather than on a phone screen, the question is how to reach it under a basis that holds up. That is the work described here.

What data sits inside the account

Each row below is a surface GoodScore actually presents to a logged-in user, where it comes from, how fine-grained it is, and why an integrator would want it.

Ways in, and the one we'd pick

Three routes genuinely apply to GoodScore. Each reaches a slightly different cut of the data.

Authorized interface integration of the in-app surfaces

We analyze the traffic the app makes after login and reproduce the calls that return the score and the account-level report, operating under the consumer's authorization. This is the only route that returns GoodScore's own assembled view — the merged Experian/CRIF report exactly as the user reads it. Effort is moderate; durability depends on the app's release cadence, which we account for with re-validation.

RBI Account Aggregator consent (AIS)

For the underlying bank balances, loan accounts, EMI status and card statements, the Account Aggregator network returns structured, consent-gated data through a licensed consent manager. This is the most durable basis for the financial-account layer because it is regulator-defined. It does not return the bureau report itself — that is the boundary between this route and the first.

User-consented credential access

Where a consenting user authorizes it, we operate the session on their behalf to retrieve their own report. Lighter to stand up, useful for a single-user or pilot pull; we handle the access setup with you during onboarding.

For most buyers the first route carries the project: it is the only one that yields the account-by-account report GoodScore actually composes, and we pair it with Account Aggregator consent when the raw bank and loan data behind the report needs to be pulled in its own right. Native report export the app offers can serve as a backstop for occasional, low-volume needs.

A request, sketched

Illustrative only — exact paths, headers and the token chain are confirmed during the build against the live app. It shows the shape: authenticate, refresh, then read the report payload.

POST /v1/session/token            # auth, confirmed during build
{ "device_id": "...", "auth": "<consumer-authorized>" }
  -> 200 { "access_token": "...", "expires_in": 3600 }

GET /v1/report?bureau=experian    # one call per bureau
Authorization: Bearer <access_token>
  -> 200 {
       "score": 762,
       "as_of": "2026-06-01",
       "accounts": [
         { "lender": "...", "type": "credit_card",
           "balance": 18450, "utilization": 0.31,
           "status": "active", "dpd_history": ["0","0","30"],
           "opened": "2021-04", "enquiries_90d": 1 }
       ]
     }

# normalize experian + crif into one account schema
# handle 401 -> refresh; handle monthly-refresh gaps gracefully

What lands in your repo

• An OpenAPI/Swagger spec for the score and report endpoints as they behave for GoodScore, both bureaus covered.
• A protocol and auth-flow report documenting the token issue/refresh chain observed during the build.
• Runnable source — Python or Node.js — for login, score read, full report pull, and the Experian/CRIF normalization step.
• Automated tests covering the auth refresh path and the monthly-refresh edge cases.
• A normalized account-level schema so both bureaus map to one structure.
• Interface documentation plus consent and data-retention guidance fitted to the RBI regimes below.

Consent and the Indian rule set

This is an India-only credit data problem, so two RBI regimes frame it. Bank, loan and card data moves under the Account Aggregator framework — the NBFC-AA Master Direction the RBI first issued in 2016 — where nothing is retrieved without the consumer's explicit, scoped, revocable consent passing through a licensed consent manager. The bureau report itself sits under the Credit Information Companies (Regulation) Act, 2005, the statute under which Experian and CRIF High Mark are licensed; access there runs on the consumer's own authorization, with consent records retained as RBI's reporting directions require. We build consent scope, expiry and revocation handling into the integration, log access, minimize what is pulled to what the use case needs, and work under NDA where the engagement calls for it.

Engineering specifics we handle

Things particular to GoodScore that shape the build:

• Two bureaus, two report shapes. Experian and CRIF return structurally different reports; we normalize both into one account-level schema so downstream code never branches on which bureau a record came from.
• The score refreshes monthly, not continuously. We pace the sync to the bureau refresh cycle rather than polling for changes that cannot have happened yet, which keeps both the integration and the source quiet.
• The SMS-based expense layer is device-local and rests on a separate permission than the bureau report. We keep that extraction path isolated so each data class carries its own consent basis instead of being blended.
• App releases move the front end. We wire re-validation into maintenance so a client release that shifts the report calls is caught and patched rather than failing silently.

Pricing

Runnable source for the GoodScore score-and-report endpoints starts at $300, and you pay it only after delivery, once you have seen the integration work against the live surfaces. If you would rather not run anything yourself, we host the integration and you call our endpoints, paying per call with no upfront fee. Either way the build cycle is one to two weeks. Tell us the app and what you need from its data, and we set up the access and compliance side with you — start at /contact.html.

Freshness and reliability

Bureau data in GoodScore turns over on a monthly cadence, so the integration is designed to read once per refresh window and cache between, rather than hammer the source. The auth token is short-lived; the source includes a refresh path that survives expiry mid-pull. When a bureau temporarily returns no fresh report, the client reports the gap instead of presenting stale data as current.

In-app surfaces

Screens from the listing, useful for confirming which fields are rendered where. Select to enlarge.

Similar apps in the same data space

Others in India's credit-monitoring category hold comparable data, which matters when a project needs one unified integration across several:

• OneScore — credit monitoring across bureaus, score tracking without heavy product cross-sell.
• CRED — credit card bill payment with a credit score view layered on the account.
• Paisabazaar — pulls from all four bureaus, including CIBIL and Equifax, with report analysis.
• Oolka — credit health and card management with bureau data.
• CreditSeva — credit report access and dispute support.
• Freo — credit line and score tracking on a neobanking account.
• Bajaj Finserv — score checks bundled with lending and EMI products.
• Paytm — score view alongside payments and a broad financial account.

Questions integrators ask about GoodScore

Can you return GoodScore's account-by-account analysis, or only the headline score?

Both. The headline number is the easy part. The value sits in the report detail the app surfaces per tradeline: balances, payment history, defaults, utilization, credit mix and enquiry records. We map those fields, not just the score figure, so a downstream model gets the same granularity a user sees in the app.

GoodScore is powered by Experian and CRIF High Mark. Do we get both bureaus, and in one schema?

Both bureaus are in scope. Experian and CRIF return their reports in different structures, so part of the build is normalizing them into one account-level schema. The consumer of the integration sees consistent fields whether a given record came from Experian or from CRIF High Mark.

Which Indian regime covers pulling this credit data?

Two apply. Bank, loan and card data flows under the RBI Account Aggregator framework on explicit consumer consent. Bureau report data itself sits under the Credit Information Companies (Regulation) Act, 2005, where access runs on the consumer's authorization and consent records are retained as RBI directs. We build to whichever basis fits the data being pulled.

The app reads SMS to track expenses. Can that data be part of the integration?

It can, but it is a separate path. The SMS-derived expense and bill data is device-local and rests on a different consent than the bureau report, per the app's own permission notice. We keep the two extraction paths apart so each carries its own consent basis rather than blending them.

How this was checked, and against what

Written from the app's Play Store listing and description, cross-checked against the RBI Account Aggregator framework, the Credit Information Companies (Regulation) Act, and reporting on the company. Sources opened:

• GoodScore on Google Play (com.rupicard.score)
• Account Aggregator framework — Department of Financial Services
• RBI-licensed credit information companies (CICRA 2005)
• GoodScore Series A coverage — Inc42

Mapping reviewed June 2026 by the OpenBanking Studio integration desk.