Pulling a Kamina user's debts and financial-health index into your own systems

Every Kamina account carries a financial-health index that the app recomputes monthly from the user's logged debts, income and spending, a self-diagnostic test, and a pulled credit-bureau score. That index, and the records under it, is the asset a partner wants in its own systems. It lives behind an authenticated account on Kamina's servers, not in any file the user can hand you. Reaching it cleanly is the whole job, and in Mexico it is shaped by an open-finance law whose data-sharing pipes are written but not yet built.

The data Kamina keeps per user

These rows reflect surfaces Kamina describes on its own consumer pages and Play listing, not a generic personal-finance checklist.

Getting to that data, the authorized way

Three routes apply here. Only one is worth recommending today.

Authorized interface integration / protocol analysis

We work the app's own authenticated traffic under your authorization: session and token handling, the calls that return the index, the debt list and the ledger, and the response shapes. Reachable: effectively everything the user sees in the app. Effort: moderate, mostly in mapping the auth chain and the index payload. Durability: good, with maintenance when Kamina ships a new build. We set up the working account and authorization with you at onboarding.

User-consented credential access

Where the integration is per end-user, the user consents and the data is read on their behalf within that consent. Reachable: the full account for that user. This pairs well with the route above for products that enrol users one by one.

Regulated open-finance feed (Ley Fintech Art. 76)

On paper this is the cleanest path. In Mexico it is not usable yet, for the reason set out below. We keep the mapping portable so it can move onto a regulated feed once the CNBV operationalizes one.

What we would actually do: build on authorized interface integration of the consenting account now, structured so a regulated feed is a later transport swap rather than a rewrite. That gives you the data this quarter without betting the schedule on a rule that has slipped for years.

Open finance in Mexico: the law is written, the pipes are not

Kamina's data sits under Mexico's Fintech Law (Ley para Regular las Instituciones de Tecnología Financiera, enacted March 2018). Article 76 mandates open finance and defines three data tiers — open data, aggregate data, and transactional data, the last requiring the user's prior written consent. The regulators are the CNBV and Banxico. Here is the part that decides the route: the secondary provisions that would actually operationalize transactional-data sharing have never been published. The CNBV's statutory window to issue them lapsed years ago; a CNBV pilot with the Open Bank Project produced technical and consent specifications that were never adopted as binding rule; and in December 2025 entrepreneurs filed an amparo naming the CNBV, Banxico and SHCP over the omission, with coverage following in January 2026. We do not state day counts or thresholds as settled fact, because the rule itself is not settled.

The practical consequence is clean. A live regulated transactional-data API is not the basis for a Kamina build today. The dependable basis is the user's own authorization and consent over their account, which is also the legal footing Article 76 itself rests transactional access on. We operate that way regardless: authorized or user-consented access only, consent and access logged, data minimized to the fields you scoped, and an NDA where the engagement needs one.

What lands in your repository

Each deliverable is tied to a real Kamina surface, not a template.

• An OpenAPI/Swagger specification covering the index read, the debt-register list, the income/expense ledger and the bureau-score snapshot, with the consent scope annotated per field.
• A protocol and auth-flow report: how Kamina's session, token refresh and cookie chain behave, and where the index payload is assembled.
• Runnable source for the key endpoints in Python and Node.js — authenticate, read index plus components, page the debt list, pull the ledger.
• Automated tests against recorded fixtures, including the monthly-recompute case so a changed index does not silently break your store.
• Interface documentation a developer can follow without us, plus retention and consent-handling notes specific to the bureau field.

A concrete pull: the index and the debt list

Illustrative shape only; exact paths and field names are confirmed against the live build during the engagement.

# Authorized interface integration — consenting Kamina account
session = kamina.login(user_token)          # OAuth/token chain mapped in the auth-flow report

idx = session.get("/v1/health-index?include=components")
# {
#   "month": "2026-05",
#   "score": 612,
#   "components": { "savings": 0.41, "debt": 0.58,
#                   "spending": 0.66, "planning": 0.5, "automation": 0.3 },
#   "computed_at": "2026-05-03T11:20:08Z"     # snapshot + pin this per pull
# }

debts = session.get("/v1/debts?sort=priority")
for d in debts["items"]:
    record(d["id"], d["balance"], d["priority"], d["urgency"])

bureau = session.get("/v1/bureau/score")      # consent-gated; separate audit trail
if not bureau.consented_scope("bureau_read"):
    skip("bureau", reason="outside scoped consent")   # never fetched implicitly

# Errors: 401 -> refresh token; 409 -> index recomputing, retry after window

Engineering realities we plan around

Two notes that matter for this app, written as things we handle on our side.

• The bureau score is the sensitive surface. Kamina pulls a Buró de Crédito score on the user's behalf. We design the integration so that field is read only inside the consent the user already granted the app, logged on its own trail separate from the rest, and excluded from any sync the client has not explicitly scoped. It is never fetched implicitly with the index.
• The index is a moving number. It recomputes monthly and its component weights shift across savings, debt, spending, planning and automation. We version the index schema and pin a snapshot with each pull, so a mid-cycle recompute does not rewrite values already in your store and historical comparisons stay honest.
• Two account contexts, not one. Kamina reaches users both inside partner banks' channels and through its standalone app, and behaviour differs by partner. We scope the build to the specific context you control and confirm field availability there rather than assuming the contexts are identical. When Kamina ships a new app build, session and field mapping can move; keeping the integration matched to the current build is part of the maintenance we carry, not a one-time capture.

Where teams put this data to work

• A partner bank mirrors each enrolled customer's monthly index into its CRM to segment delinquency risk before it becomes arrears.
• A lender reads the consented debt register plus the bureau snapshot to pre-fill a consolidation offer the customer can accept in one screen.
• An aggregator normalizes Kamina's income/expense ledger into a single schema next to other linked accounts.
• A collections team surfaces Kamina's over-indebtedness prediction as an early-warning signal inside its existing workflow.

Cost and how the build runs

Handoff for Kamina is a Git repository plus a runnable OpenAPI file, delivered in a one to two week cycle. Source-code delivery starts at $300: you receive the runnable source, the spec, the tests and the docs, and you pay after delivery once you are satisfied it works. The hosted option is pay-per-call: we run the endpoints, you call them, you pay only for the calls you make, with no upfront fee. You give us the app name and what you need from its data; access, the working account and any compliance paperwork are arranged with you as part of the engagement. Tell us which fits and what you are building — start the conversation here.

Screens we mapped

The app's own screenshots, used to trace which surfaces hold what. Select to enlarge.

Kamina among Mexico's money-health apps

Same-category apps an integrator often unifies alongside Kamina. Named for ecosystem context, not ranked.

• Fintonic — bank-account aggregation with fee and unusual-charge alerts; transaction-level data behind a linked-accounts model.
• Mobills — budgeting and multi-card management; per-card balances and categorized spend.
• Monefy — manual expense tracker; locally entered categories rather than linked accounts.
• Finerio Connect — account aggregation and PFM infrastructure in Mexico; normalized transaction feeds.
• Coru — financial-coaching and product-matching profiles tied to a user's stated finances.
• Zenfi — free Buró de Crédito score consultation and debt guidance; credit-history records.
• Intuit Credit Karma — credit-score monitoring; bureau-derived score and report data.
• Stori — credit card for the underbanked; in-app statement and repayment history.
• Kueski — short-term loans and pay-later; per-loan balances and a repayment ledger.

What we read, and when

We reviewed Kamina's own consumer pages and Play listing for the data surfaces, and primary regulatory and legal coverage for Mexico's open-finance status. Checked 2026-05-19. Primary references: Kamina — consumer app features, Kamina on Google Play, Holland & Knight — Open Banking Has Arrived in Mexico, FinTech Futures — CNBV facing legal action over open-finance rule delays. Compiled by OpenBanking Studio's integration desk; surfaces re-checked 2026-05-19.

Questions integrators ask about Kamina

Can you pull the Buró de Crédito score Kamina shows, or only the in-app index?

Both are reachable under the consent the user already gave the app. The bureau score is the most sensitive field on the account, so we fetch it only within that existing consent, log it on its own trail, and leave it out of any sync the client has not explicitly scoped.

Mexico's open-finance secondary rules still are not published. Does that block this build?

No. The integration runs on the consenting Kamina account through authorized interface integration, not on the transactional-data API that the CNBV has not yet operationalized. We track CNBV and Banxico progress and can move the same mapping onto a regulated feed if and when one goes live.

Does the financial-health index arrive as a single number or with its parts?

We map both: the headline monthly index and the component view behind it (savings, debt, spending, planning, automation). Each pull is snapshotted with its timestamp so a monthly recompute does not rewrite values you already stored.

We run only the bank-embedded side of Kamina, not the standalone app. Can you still help?

Yes. We scope the build to whichever account context you control, embedded-partner or standalone, and the access for that context is arranged with you during onboarding.