Reaching the loan ledger behind Finanzas Ágiles-Crédito Fácil

What a Finanzas Ágiles account carries

Every row below is a surface the app exposes to its own user. The integration mirrors the ones a given project needs, normalized into stable field names.

A repayment-schedule pull, sketched

The figures below match the worked example in the app's own listing — a $20,000 MXN loan over 180 days at the 0.1%/day ceiling gives $600 of monthly interest on a $3,333 monthly principal. Paths and field names are illustrative; they are confirmed against live traffic during the build, not asserted from the store page.

# 1) Authenticate the INE-backed account; MFA folded in where the app uses one.
POST /session/login
  { "phone": "+52...", "password": "..." }
  -> { "access_token": "...", "refresh_token": "...", "expires_in": 1800 }

# 2) Pull the amortization schedule for one loan.
GET /loans/{loan_id}/schedule
  Authorization: Bearer <access_token>
  -> {
       "loan_id": "...",
       "principal_mxn": 20000,
       "term_days": 180,
       "daily_rate": 0.001,            # 0.1%/day, the listing's ceiling
       "installments": [
         { "n": 1, "due": "2026-07-15", "principal_mxn": 3333,
           "interest_mxn": 600, "status": "scheduled" },
         { "n": 2, "due": "2026-08-15", "principal_mxn": 3333,
           "interest_mxn": 600, "status": "scheduled" }
         # ...
       ]
     }

# 3) Each status move (scheduled -> due -> paid | extended | late) is emitted
#    onto a queue. A consumer that falls behind replays from its last
#    acknowledged offset, so a dropped connection never loses an installment.
        

What lands in your repo

The package is built around code that runs on day one against this app's surfaces:

• Runnable client source in Python and Node.js — login, token refresh, schedule pull, and payment/status reads, written against the real auth chain.
• A queue consumer with replay for loan-state events, so application, approval, installment, and payment changes arrive in order and a late consumer catches up from its offset.
• A poller/normalizer that turns the app's installment and payment surfaces into stable event envelopes when a push feed is not available.
• An automated test suite over recorded fixtures, covering the token chain and the schedule math so the installment figures tie out to the MXN amounts the app shows.
• An OpenAPI/Swagger description of the mapped surfaces, for teams that want a spec alongside the code.
• A protocol and auth-flow report (token and cookie chain as it actually behaves), interface documentation, and data-retention guidance for the INE and payment fields.

Three authorized ways in

User-consented account access (what we would run today)

The borrower authorizes the read, and we drive the authenticated session on their behalf. This reaches the full loan lifecycle — schedule, payments, status — and is durable as long as re-authorization is handled with the user. It is the route we recommend now, because it does not wait on a regulator timetable. We arrange the consenting account or sandbox with you during onboarding.

Authorized interface integration / protocol analysis

Under the customer's authorization, we map the app's own traffic — the login exchange, the token refresh, the schedule and payment calls — and reimplement them as a clean client. Effort is moderate; durability depends on how often the app revises its surfaces, which our test suite catches early.

Regulated open-finance consent (where this is heading)

Article 76 of the Ley Fintech mandates transactional-data APIs under explicit client consent, supervised by the CNBV and Banxico. The secondary rules for that tier are still pending, so we treat it as the forward path rather than a live channel, and design the consent model so a project can move onto it cleanly once the rules publish. Where the app surfaces an in-app statement a borrower can export, that export is a thin fallback for one-off pulls.

Consent and the Mexican rulebook

Two regimes touch this app. The Ley Fintech (in force since March 2018) sets the open-finance frame: Article 76 obliges financial entities to share data through standardized APIs across three tiers — open data, aggregate data, and transactional data — with the transactional tier requiring the customer's prior consent. Only the open-data tier is operative today; the CNBV published its general provisions for it in the Official Gazette on 4 June 2020 (per Holland & Knight's reading of the rules), while the transactional-data secondary rules remain unpublished, a delay that drew an amparo filing in late 2025. So this page does not lean on the transactional regime as settled law — the borrower's own authorization is the basis we build on.

Separately, the LFPDPPP governs the personal data the app collects — the INE image, contact details, the loan record. We operate accordingly: access is authorized and logged, the identity image is data-minimized to the fields a use-case actually needs, consent records are kept, and an NDA is in place where the engagement calls for one. Because a Mexican lender of this kind typically reports to Buró de Crédito or Círculo de Crédito, we keep the integration's read path clear of any write into those bureaus.

What we plan around for this app

These are specifics of Finanzas Ágiles we account for, not things we ask you to solve first:

• Daily-rate against APR. The app quotes both a daily rate (0.01%–0.1%) and an APR (3.6%–36%), and shows installment amounts derived from them. We build the schedule math to reproduce the displayed figures exactly — principal split evenly across the term, interest as principal × daily rate × days — and surface rounding so a downstream ledger ties out to the peso rather than drifting by centavos.
• Early payment and extension rewrite the loan. Both are first-class features in the app. We model each as a schedule-rewrite event, so a consumer recomputes the remaining principal-and-interest split from the new state instead of holding a stale amortization table.
• Session and consent lifetime. Authenticated sessions and tokens expire well before a 180-day loan does. We size the sync window to the session lifetime and arrange renewal with the borrower, so a long-running read is refreshed deliberately and stays attributable to a consent record.

Cost, and how the build runs

The source-code package starts at $300, billed only after it is delivered and you have checked it against your own account — runnable Python and Node.js clients, the queue consumer with replay, the test suite, and the interface docs, yours to host. If you would rather not run any infrastructure, the same surfaces are available as a pay-per-call hosted API: you call our endpoints and pay for the calls you make, with nothing upfront. Either way the work runs on a one-to-two-week cycle against a consenting account or sandbox we set up with you. Tell us the app and what you need from its data to get started — start a project at /contact.html.

What teams build with it

• A lending aggregator that mirrors a borrower's outstanding balance and next due date across several apps in one view.
• A servicing or collections dashboard that ingests installment-status changes as they happen and triggers respectful, timed reminders.
• An accounting sync that posts the principal-and-interest split of each payment into a general ledger.
• A credit-data product that reconciles the loan record against what is reported to Buró de Crédito or Círculo de Crédito.

Screens we mapped against

Store screenshots of the application, schedule, and payment flows — the surfaces the integration reads. Select to enlarge.

How this brief came together

Written from the app's own Google Play listing and privacy notice, cross-checked against current Mexican open-finance regulation in June 2026. Loan terms and the worked interest example come from the listing; the regulatory status — Article 76, the three data tiers, the June 2020 open-data provisions, and the still-pending transactional rules — is drawn from the sources below.

• Finanzas Ágiles-Crédito Fácil on Google Play — loan range, terms, rates, requirements.
• Holland & Knight: Open Banking Has Arrived in Mexico — Article 76, the three data tiers, and the 4 June 2020 CNBV provisions.
• Finerio Connect: Open Banking y su regulación en México — datos abiertos / agregados / transaccionales and the consent requirement.
• FinTech Futures: CNBV faces legal action over delayed open-finance rules — the pending transactional-tier secondary rules.

Compiled by OpenFinance Lab — interface engineering, 15 June 2026.

Other Mexican lending apps in the same set

Teams that integrate Finanzas Ágiles usually want the same loan-lifecycle read across the wider short-term-credit market. Neighbouring apps, each holding comparable records:

• Kueski — one of Mexico's larger short-term lenders; per-user loan, disbursement, and repayment records behind an account.
• Tala — small-ticket loans with short terms; holds application, approval, and installment data per borrower.
• Credilikeme — first-loan and rewards-style credit; carries loan balances and a repayment ledger.
• Moneyman — instalment loans up to mid-five-figure MXN amounts; per-account schedules and payment history.
• AvaFin — larger personal-loan lines; application, approval, and amortization records per user.
• Kimbi — first-loan-free online credit; holds loan status and a payment schedule per borrower.
• Cozmo — short-term credit operated by a registered SOFOM; per-user loan and repayment records.
• Crédito365 — short-cycle loans; application, schedule, and payment data behind an account.

Listed as an ecosystem map, not a ranking — a unified integration treats them as one normalized loan-and-repayment model.

Questions integrators ask

After an early payment or an extension, how does the integration keep the repayment schedule correct?

Both actions rewrite what is left of the loan — an early payment shortens it, an extension stretches it. We model each as a schedule-rewrite event, so a downstream ledger recomputes the principal-and-interest split from the new state instead of drifting away from what the borrower sees in the app. A consumer that missed an event replays it from the queue.

Does the build reach the INE and identity data, or only the loan figures?

Both are technically in the account, but we scope to the use-case. A collections or accounting sync usually needs only the loan, schedule, and payment records; an onboarding or KYC use-case touches the INE-backed identity fields, which we then keep minimized, access-logged, and out of any cache that does not need them.

Mexico's open-finance transactional rules are not published yet — does that block the integration?

No. The basis we rely on today is the borrower's own authorization to reach their account, not the pending CNBV transactional-data regime. Article 76 of the Ley Fintech mandates those APIs and the secondary rules are still awaited, so we treat the regulated path as where this is heading and build now on user-consented, authorized access.

How soon can a first working pull against a Finanzas Ágiles account run end to end?

Usually one to two weeks for a single-app loan surface like this — the auth chain, a schedule pull whose figures match the app's MXN amounts, and a test suite against recorded fixtures. Access is arranged with you and a consenting account during onboarding.