Zenfi ties Buró de Crédito, the SAT and your cards to one login

Three separate Mexican backends answer to a single Zenfi account. One is Buró de Crédito, where the report and the score live. The second is the SAT, the federal tax authority, which holds the user's fiscal profile and their invoices. The third is the user's own linked cards and the income-and-expense history Zenfi builds on top of them. Most of the integration questions teams bring us about this app come down to one thing: they want one or two of those three feeds in their own system, normalized, under the user's consent — without rebuilding Zenfi's analysis layer by hand.

What sits behind a Zenfi login

The data domains below are the surfaces the app actually exposes to a signed-in user, named the way Zenfi names them. The origin column matters here more than usual: each row reaches a different system, with a different owner and a different consent step.

The bottom line is that this is not one feed wearing three hats. It is three feeds the app has already done the hard work of joining. An integrator usually wants the join logic for the score drivers, but the raw bureau, SAT and transaction data is more durable when reached at the source. That shapes the route choice below.

Routes to the data, and the one I'd pick

Two or three routes genuinely apply to Zenfi. They are not ranked in the abstract — the right mix depends on which of the three sources you actually need.

Protocol analysis of the app's own traffic

We observe and document the request/response chain the app uses after sign-in, then reimplement it. This is what reaches Zenfi's analysis layer — the score drivers and the readable bureau summary the app assembles. Effort is moderate; durability is tied to the app's front end, so we account for change here rather than pretend it stays fixed. Access is arranged with you during onboarding, against a consenting account.

User-consented access at each source

For the parts that are source-of-truth, we go straight to the source under the user's authorization: the bureau report via a consent-based consultation, the SAT data via the taxpayer's own credentials (RFC with contraseña or e.firma) against the SAT service, and card data via direct linking. Higher effort per source, but this is the durable path — it does not move when Zenfi reskins a screen.

Native export, where it exists

Zenfi lets users download documents such as the Constancia de Situación Fiscal. That covers a narrow slice and is useful as a verification cross-check, not as the spine of a live feed.

For most briefs I would reach the bureau report and the SAT profile at the source under consent, because those are the records you cannot afford to have drift, and use protocol analysis only for the score-driver and tip layer that is genuinely Zenfi's own work. If all you need is the score number for monitoring, the app-traffic route alone is the faster build.

A worked pull: the bureau summary

Illustrative only — field names and shapes are confirmed during the build against a consenting account, not asserted here as Zenfi's production contract. It shows the pattern we document: an authorized session, a consent reference, then the summary read.

POST /auth/session          # exchange user credentials for a short-lived token
  -> { "access_token": "…", "expires_in": 900 }

# bureau read carries the user's consent reference; score check is a soft pull
GET /v1/bureau/summary
  Authorization: Bearer <access_token>
  X-Consent-Id: cns_… (timestamped authorization captured in-flow)

200 OK
{
  "score":            { "value": 712, "pull_type": "soft" },
  "utilization_pct":  31,
  "accounts_active":  6,
  "inquiries_12m":    2,
  "identity_alerts":  0,
  "experience_years": 9,
  "drivers": [
    { "factor": "payment_punctuality", "impact": "high",   "status": "good" },
    { "factor": "utilization",         "impact": "medium", "status": "improve" }
  ]
}

# handle the cases that actually occur:
#   401 -> token expired, re-run /auth/session
#   409 -> consent missing or revoked, re-capture before retry
#   429 -> back off; the bureau side rate-limits consultations

The same skeleton, with a different path and a CAPTCHA/2FA step, is what the SAT side looks like. We document both, with the error branches, because the 409-on-revoked-consent case is the one that quietly breaks a monitoring product if it is ignored.

What lands in your repository

Each deliverable is tied to the surfaces above, not a generic checklist:

• An OpenAPI/Swagger specification covering the endpoints you take — bureau summary, score, SAT profile, CFDI list, or transactions.
• A protocol and auth-flow report: the token exchange, the consent reference, the SAT credential and CAPTCHA path, and how each session refreshes.
• Runnable source for the key reads in Python or Node.js, including the soft-pull handling so monitoring never trips a hard inquiry.
• Automated tests against recorded fixtures, plus the 401 / 409 / 429 branches shown above.
• Interface documentation, and consent-and-retention guidance written for the Mexican rules that apply to each source.

You can take one module or the full join. A team that only needs SAT verification gets the SAT layer and nothing it will not use.

Consent and Mexico's data rulebook

Three different rules govern the three sources, and that is the point worth getting right. The bank and transaction tier falls under the Ley para Regular las Instituciones de Tecnología Financiera — the Ley Fintech — whose Article 76 obliges entities to share information through standardized APIs across three tiers: open data, aggregate data, and transactional data, the last requiring the client's prior written consent (per Holland & Knight's reading of the law). The CNBV published its first implementing provisions in mid-2020, and the CNBV and Banco de México jointly oversee the framework. The transactional tier, though, is still being rolled out — binding secondary rules for client-level account sharing have not landed — so we do not treat it as a finished rail. The dependable basis today is the user's own consent and direct linking; the Ley Fintech rails are where this can move once they are in force, not what it stands on now.

The bureau data sits under a different statute, the Ley para Regular las Sociedades de Información Crediticia, which ties each consultation to the consumer's authorization. The SAT data is reached with the taxpayer's own credentials, so the consent there is simply the user acting as themselves. Across all three, we keep access authorized and logged, store consent records with timestamps, minimize what we pull to the fields you asked for, and work under an NDA where the engagement needs one.

Engineering realities we plan around

Two or three things about Zenfi shape how we build, and we handle them rather than hand them to you:

• Three consent lifecycles, not one. The bureau authorization, the SAT credential session, and the card link each expire on their own clock. We design token and consent refresh per source so one going stale does not silently take the whole feed down.
• Soft-pull fidelity. The score is read as a soft consultation that does not affect the file. We preserve that consultation type deliberately, so a long-running monitoring integration never converts into hard inquiries against the user.
• SAT-side friction. The SAT portal throws CAPTCHA and credential challenges and changes its responses without notice. We keep a check that flags when the SAT or the app's payloads shift and refresh the parser before it breaks in production.

Access — a consenting account or the relevant credentials — is set up with you during onboarding. It is part of the project, not a hurdle you clear before we start.

Where a Zenfi-style feed gets used

• A lender wants the bureau summary and the SAT Opinión de Cumplimiento on the same applicant, joined at decision time.
• A B2B platform verifies a new supplier's RFC and tax regime against the live Constancia rather than a stale PDF.
• A personal-finance product pulls categorized transactions and the score trend to show a user their progress month over month.
• An SMB-credit team reads CFDI invoices sent and received to model real cash flow instead of self-reported figures.

Screens we mapped

Store screenshots we referenced while mapping the surfaces above. Click to enlarge.

Sources and when we checked

Mapped against Zenfi's store listing and its feature description, then cross-checked the Mexican rules in June 2026. The legal framing leans on Holland & Knight's analysis of the Ley Fintech and a current open-finance status tracker; the SAT data points come from documentation on the Constancia de Situación Fiscal and the SAT web service. Primary sources opened:

• Holland & Knight — Open Banking Has Arrived in Mexico (Article 76, the three data tiers)
• Fiskil — Mexico open-finance status tracker
• SAT — Constancia de Situación Fiscal via SAT ID
• Zenfi — Google Play listing (mx.zenfi.app)

Mapping reviewed by the OpenBanking Studio integration desk — 2026-06-15.

The Mexican financial-health neighborhood

Same-category apps and infrastructure an integrator runs into when unifying credit and finance data in Mexico, named for keyword context, not ranked:

• Coru — comparison and application platform for credit cards, loans and insurance; holds product-fit and application data.
• Klar — a neobank whose app tracks card spending and balances on top of its own accounts.
• Kueski — consumer lending and buy-now-pay-later; holds loan and repayment records per user.
• Destacame — debt-management and alternative-credit scoring built on a user's payment behavior.
• Rocket — surfaces credit-bureau information so users can read and manage their credit status.
• Rokin — personal-finance management with budgeting and goal data.
• Finerio Connect — account-aggregation infrastructure that normalizes bank and card data for other apps.
• Belvo — an open-finance aggregator exposing bank, fiscal and employment data through a single connection.

Questions integrators ask about Zenfi

Can you split the SAT tax data from the credit-bureau data, or does it come as one feed?

They are separate modules. Zenfi joins three sources behind one account, but the bureau report, the SAT tax profile and the card/transaction history each reach a different backend with its own auth. We can build and hand over just the SAT layer, just the bureau layer, or the full join — whatever your product needs.

Does reading the score the way Zenfi does register as a hard inquiry on the bureau?

No. The app describes its score check as one that does not damage the file, which is a soft consultation. We mirror that consultation type so a monitoring integration keeps reading the score without logging a hard inquiry against the user.

Whose authorization do you need to pull the Buró de Crédito report?

The end user's. Credit-information access in Mexico runs under the Ley para Regular las Sociedades de Información Crediticia, which ties each consultation to the consumer's authorization. We capture that consent in the flow and keep a timestamped record of it alongside every pull.

Is Mexico's open-finance rule something I can rely on for the bank and transaction tier today?

Not yet as a finished rail. Ley Fintech Article 76 names a transactional data tier, but binding secondary rules for it have not been published, so we rest the bank and card side on the user's own consent and direct linking now, and can move it onto the Ley Fintech rails once they are in force.

Starting a Zenfi build

A working integration against Zenfi's surfaces typically lands inside one to two weeks. Source-code delivery starts at $300: you get the runnable code, the spec, the tests and the docs, and you pay only after we hand it over and you have confirmed it runs. If you would rather not run anything yourself, call our hosted endpoints instead and pay per call, with nothing upfront. Either path, you give us the app name and what you want out of its data; we arrange access and the consent setup with you. Tell us what you need at /contact.html and we will scope it.