Reaching HolaFina's borrower ledger through authorized interface integration

What we found on HolaFina

HolaFina describes itself as a quick-loan app — five-minute application, same-day deposit — for Mexican adults with an INE/IFE and a domestic bank account, per its Play Store listing. Loan ceiling is given there as MXN 50,000, with annual rates between 31.07% and 257.51% excluding VAT, and a representative term of 120 days at 0.3% per day. None of those numbers were confirmed against an internal portal during this brief; they shape the schedule format an integration has to read, and the build re-confirms them on a live account.

The honest read: HolaFina is a single-product lender, not a multi-product bank. There is one loan at a time per borrower in the typical state. The integration job is narrow, well-defined, and finishes inside the studio's normal cycle.

What data HolaFina actually holds about a borrower

The portal surfaces these data domains. The right column is the integration's reason for reading each one.

Routes that reach a HolaFina account, ranked by effort

Authorized interface integration against the borrower portal

The route we actually use. We map the request/response shapes the HolaFina Android app exchanges with its backend, then drive those calls server-side under a borrower's explicit, recorded consent. Reachable: every domain in the table above. Effort: low to moderate for a single-product lender like this one. Durability: holds as long as the portal protocol holds; a breaking UI redesign triggers a re-map, which the studio absorbs as a maintenance pass. Access is arranged with you during onboarding — a consenting borrower account on your side, a paired test account through a HolaFina partnership, or both — and the build runs against that.

User-consented credential access (RPA-flavoured)

Where a per-borrower flow is preferable to a server-driven one — for example, a personal-finance app showing a user their own HolaFina position — the integration is driven by the user's own session. Reachable: the same data, with each pull tied to the user's interactive consent. Effort: moderate; the trade-off is freshness depending on session lifetime. Durability comparable to the portal route.

Mexico's Open Finance regime, where applicable

Article 76 of Ley Fintech obliges Mexican financial entities to share data through standardized APIs. CNBV has issued provisions for the open-data and aggregated layers, with transactional-data secondary regulations still pending in 2025–2026. For a SOFOM-track lender, the transactional layer is the one that would matter to a third party. We track CNBV's publications and move the integration onto that layer as soon as HolaFina's category is in scope and the technical specification stabilizes; today the borrower-consent route is the practical answer.

For HolaFina specifically the route that ships work in 1–2 weeks is the authorized portal integration, with the open-finance migration kept on the roadmap rather than the critical path.

The source you receive at the end

The deliverable for HolaFina is concrete, not a deck. It contains:

• An OpenAPI 3.1 specification of the borrower-portal endpoints we use — login, session refresh, KYC status, loan-position read, schedule read, repayment list — with HolaFina's actual field names preserved and an English gloss alongside.
• A protocol & auth-flow report documenting how the Android client opens its session, where the token lives, how it refreshes, and what the server expects on each call. Cookie chain, CSRF posture, error surfaces.
• Runnable Python source (FastAPI + httpx) and a parallel Node.js TypeScript build, both implementing the same endpoint set against the same OpenAPI contract.
• A normalized loan-ledger schema mapping HolaFina's fields onto a portable shape — borrower, loan, schedule, events — so downstream systems are not coupled to HolaFina-specific keys.
• An automated test suite that hits a paired test or consenting account, asserts the schedule reconciles against the daily-accrual rate, and flags drift.
• An interface-documentation site (Markdown + a rendered HTML) covering setup, secrets handling, consent records, error replay, and the maintenance routine when the portal shifts.
• A short compliance note pinning the corporate vehicle, the CONDUSEF SIPRES entry as observed at kickoff, the consent template we used, and the data-retention windows the studio recommends.

You can host the source on your own infrastructure or, if you prefer, point at our hosted endpoints and skip the deployment work.

What the auth and ledger calls look like in practice

Illustrative — exact paths, field names and headers are confirmed against the live portal during the build. The shape is what matters here.

# POST /api/auth/session
# Bearer-style session token; refresh on 401 via /api/auth/refresh.

POST /api/auth/session HTTP/1.1
Host: app.holafintech.com
Content-Type: application/json
X-App-Build: holafina-android-{version}

{
  "phone":      "+52##########",
  "credential": "...",                # device-bound, captured at kickoff
  "device_id":  "..."
}
-->
{
  "session_token": "eyJhbGciOi...",
  "refresh_token": "...",
  "borrower_ref":  "BRW-7c3...",
  "expires_in":    1800
}

# GET /api/borrower/loan/current
# Reads the active loan position with daily-accrued interest.

GET /api/borrower/loan/current HTTP/1.1
Authorization: Bearer eyJhbGciOi...
Accept-Language: es-MX
-->
{
  "loan_id":          "LN-2026-...",
  "principal_mxn":    10000.00,
  "accrued_interest": 184.20,         # daily rate applied since disbursement
  "vat_mxn":          29.47,
  "current_payoff":   10213.67,
  "next_due_date":    "2026-06-14",
  "days_outstanding": 18,
  "rate_daily":       0.003,          # per Play Store listing
  "term_days":        120
}

# GET /api/borrower/loan/{id}/schedule
# Returns the amortization rows the borrower sees in the app.
# Each row carries date, principal, interest, VAT and expected balance.

Errors come back as JSON with a Spanish message field — the wrapper normalizes those into a small enum (session_expired, kyc_incomplete, loan_locked, portal_drift) so downstream code does not branch on free-text strings.

The Mexican footing for HolaFina data

Consumer lending in Mexico sits primarily under the LGOAAC (Ley General de Organizaciones y Actividades Auxiliares del Crédito), with non-bank lenders typically operating as SOFOM ENR — supervised by CONDUSEF for consumer-protection and by CNBV for AML/PLD via a technical opinion. HolaFina's specific corporate vehicle and SIPRES entry are re-checked at kickoff against the public registry rather than asserted here.

The data-rights basis we use for an integration is the borrower's documented consent: scope (which data domains), duration (typically tied to loan life plus a defined tail), and a revocation path the borrower can use without contacting the studio. Personal-data handling follows LFPDPPP, Mexico's federal data-protection law, with collection minimized to what the use-case actually needs and a retention clock that starts at revocation.

CNBV's broader Open Finance rollout — aggregated data published, transactional layer still being finalized through 2025–2026 — is the medium-term path. We do not present it as today's lever, and a HolaFina build does not depend on it landing.

The moving parts we handle on a Mexican peso lender

Things specific to HolaFina that the studio accounts for during the build, so the integration is not surprised after handover:

• INE/IFE upload step. The KYC flow is image-and-OCR, not a structured ID feed. We model the upload events so a downstream KYC system can hook the moment HolaFina marks identity as verified, instead of polling and guessing.
• Daily 0.3% accrual and VAT-inclusive amortization. The schedule the borrower sees is calculated daily and VAT is layered on top. We reproduce that arithmetic in the test suite, so when reconciliation diverges the cause is portal drift, not rounding.
• Spanish-only UI strings as the source of truth. Error and status messages come back in Spanish. We map them to a stable English enum at the wrapper layer so dashboards and alerts in any language stay readable.
• Roll-over creates a new loan ID. When a borrower re-borrows, HolaFina opens a fresh ledger. The integration chains the prior and new IDs against the borrower's INE-derived reference so a downstream system sees a continuous credit relationship, not two unrelated accounts.
• Mexico City timezone, SPEI cut-offs. Repayments cleared through SPEI land on banking-day boundaries. We anchor all schedule comparisons to America/Mexico_City and align reconciliation to bank-day, not UTC, so a Sunday payment doesn't read as missed on Monday.
• Portal-drift maintenance. Mexican consumer-lender front ends change cadence quarterly or so. The handover includes a re-validation script that the studio runs on a maintenance retainer if you prefer not to own that work.

Four jobs an integrator typically needs HolaFina for

1. Borrower-side personal finance. A money app showing the user their HolaFina balance, next due date, and projected payoff alongside their bank accounts. The user authorizes pulls from their own session; the integration refreshes daily.
2. Underwriter-side credit visibility. A second lender, with the borrower's consent, reads the current HolaFina position to size its own offer against the active obligation. One-shot pull at decision time, rather than ongoing sync.
3. Repayment-automation tooling. A payments app that watches HolaFina's amortization schedule and triggers SPEI transfers from the borrower's nominated account on the due date — with reconciliation back to HolaFina's repayment events the next day.
4. Portfolio-side reporting. A partner with a referral or capital relationship to HolaFina that needs a normalized loan-tape view: principal outstanding, days past due, roll-over chains, written off vs current. The integration produces a daily CSV/Parquet against the normalized schema and stays out of the partner's analytics stack.

Where HolaFina sits next to other Mexican lenders

A normalized integration aimed at the Mexican consumer-lender slice usually covers HolaFina alongside several of these. Plain framing — naming the data each one holds — not a ranking.

• Kueski. Long-running short-term lender with an in-app loan position and a buy-now-pay-later product (Kueski Pay) on top; data shape similar to HolaFina with the addition of merchant-tied instalment plans.
• Yotepresto. Peer-to-peer lender; the borrower-side surface looks like a single loan ledger, while the investor-side surface is a portfolio of notes — two integrations in one app.
• Konfío. SME-leaning lender with credit lines, repayment schedules and a business profile, plus a card product; richer than HolaFina but the loan-ledger primitives map.
• Aplazo. Pay-in-four / instalments at point of sale; the consumer-side data is a sequence of small open positions per merchant rather than one big loan.
• Credijusto (now Covalto). Business credit; loan-tape and statement-style data, audited where a SOFOM-track entity is involved.
• MoneyMan México. Short-term consumer credit with a progressive limit and rate schedule; shape close to HolaFina.
• Crédito Maestro. Payroll-discount credit through employers; the integration angle is the loan position plus the payroll-deduction record, which HolaFina does not carry.
• Mexdin. Short-term consumer lender comparable to HolaFina; treat as a peer when an integrator wants coverage across the segment.
• Tala México. Mobile-first micro-loans with an internal credit-scoring view; loan-position primitives mirror HolaFina's.

What was checked, and against what

For this brief we worked from HolaFina's Play Store listing, its public website at holafintech.com, the CONDUSEF SIPRES registry (so the SOFOM/lender entry can be re-verified at kickoff), and the published state of Mexico's Open Finance rollout under Ley Fintech. The internal portal request/response shapes are not asserted here; they are observed during the build against a consenting account and recorded in the protocol report we hand over.

• HolaFina on Google Play — listing, terms, contact
• CONDUSEF SIPRES — Mexican financial-services provider registry
• Mexico Open Finance status (Ley Fintech, CNBV provisions)
• HolaFina official website

Mapped by the OpenBanking Studio integration desk, 30 May 2026.

Questions an integrator usually asks before kickoff

Does HolaFina expose statement-style history, or only the live loan position?

In our mapping, the borrower portal centres on the active loan: balance, accrued daily interest, the amortization schedule, and a list of past disbursements and payments tied to that account. There is no separate transaction-statement endpoint the way a bank app would expose one. To approximate a statement, we stitch together the disbursement events, the daily-interest schedule, and the repayment events into a single ledger object during the build.

Is HolaFina the kind of entity that needs CONDUSEF or CNBV cover for an integration?

HolaFina operates as a consumer lender in Mexico, which in practice is the SOFOM ENR territory governed by the LGOAAC. We re-check its current status in CONDUSEF SIPRES at kickoff and confirm the corporate vehicle behind the brand before we wire anything, because that decides what consent record we need from the borrower and what your downstream use of the data must respect.

What happens to the integration when a borrower's loan is rolled over or restructured?

Roll-overs change the loan ID in HolaFina's portal and reset the amortization. The integration treats the prior loan as closed and opens a new ledger object linked by the borrower's INE-derived identifier, so a downstream system that aggregates monthly position sees a clean transition instead of a silent jump in balance.

Can the build run against a sandbox, or do we need a live consenting borrower account?

There is no HolaFina sandbox of the open-banking kind. We arrange access with you during onboarding — typically a consenting borrower account on your side, or a paired test account if you partner with HolaFina directly — and run the build, the protocol report, and the automated tests against that.