Ximple keeps a two-layer loan ledger; here's the authorized way in

Every Aliado who signs into co.ximple sits on top of two stacked credit relationships: the working-capital line Ximple extends to them, and the smaller loans they in turn hand to their own catalog customers. That second layer is unusual. Most lending apps hold one borrower's records; here the consenting user is also a lender, so the data behind a single login spans two ledgers that have to stay separated. The integration question for Ximple is less "can the balance be read" and more "how do you keep the parent line and the downstream customer loans from contaminating each other while a third party syncs both."

Ximple is a Mexican fintech that closed a roughly US$2.7M seed round to launch its platform, per LatamFintech reporting, and later added a Mastercard disbursement card built with Dock. We treat it as an authorized interface-integration job: map the authenticated surfaces a consenting Aliado already sees, deliver runnable code against them, and slot the regulated open-finance path in where it binds. What the route reaches and how durable it is are the subject below.

Where an Aliado's credit data actually sits

These are the surfaces a consenting Aliado session exposes, named the way the product frames them. Granularity is what we have seen hold up in practice; exact field sets are confirmed per build.

Authorized paths into the ledger

Three routes genuinely apply. We name what each reaches, how durable it is, and what we set up to run it.

1. User-consented interface integration

With a consenting Aliado account, the authenticated traffic carries everything in the table above: profile, line, applications, disbursements, both repayment ledgers, card activity. Effort is moderate. Durability is medium rather than high because the product is young and still adding rails, so contracts move. Access is arranged with you during onboarding; the build runs against a consenting Aliado account or a sponsor sandbox, set up on our side as part of the project.

2. Open-finance consent under the Fintech Law

Mexico's Ley Fintech legislates open finance and obliges covered entities to expose consent-scoped data through standardized APIs. Where the secondary rules bind an entity of this type, this becomes the cleanest, most durable path: regulated, consent-bound, stable. The catch is timing — transactional-data rule-making in Mexico is still maturing, so we design route 1 to be the working spine today and fold this path in as the upgrade once it applies, rather than wait on it.

3. Native export as a narrow fallback

Where the app surfaces a statement or repayment report a user can pull, that export covers schedule and history cheaply. It is brittle and partial, useful as a reconciliation cross-check rather than the backbone.

In practice we build on the consented-interface route, normalize both ledgers and both disbursement rails behind one client, and treat the open-finance path as a planned swap-in. That keeps a working integration in your hands now without betting the timeline on a rule schedule we do not control.

What ships to your repository

Concrete artefacts, each tied to a Ximple surface rather than a generic checklist:

• An OpenAPI/Swagger specification covering Aliado profile, the working-capital line, merchandise-loan applications, disbursement events, the customer sub-loan ledger, repayment schedules and card transactions.
• A protocol and auth-flow report: the session, bearer and refresh-token chain as observed on a consenting account, including the 401-then-refresh behaviour.
• Runnable source for the key reads in Python and Node.js, with the two ledgers modelled as a parent line and linked child sub-loans.
• An automated pytest suite running against recorded fixtures so the contract is checked, not assumed.
• Interface documentation and data-retention guidance, including how the customer sub-loan payload is minimized and retained under LFPDPPP.

A credit-line read, sketched

Illustrative shape, not a published interface. Field names and the auth chain are confirmed against a consenting Aliado account during the build; amounts are placeholders.

# Illustrative only - confirmed per build against a consenting account.

POST /auth/session            # phone + OTP -> short-lived bearer; refresh rotated
  -> { "access": "...", "refresh": "...", "aliado_id": "...", "expires_in": 900 }

GET  /v1/aliado/{id}/line     # the working-capital line Ximple extends to the Aliado
  -> { "limit_mxn": 25000, "available_mxn": 9120,
       "cycle_due": "2026-06-03", "status": "active" }   # amounts illustrative

GET  /v1/aliado/{id}/disbursements?since=2026-05-01
  -> [ { "id": "...", "amount_mxn": 4000,
         "rail": "cash_network|mastercard_card",   # tag the rail; never merge
         "location_id": "...", "ts": "..." } ]

GET  /v1/aliado/{id}/customer-loans               # sub-loans granted downstream
  -> [ { "loan_id": "...", "borrower_ref": "...", "principal_mxn": 800,
         "schedule": [ { "due": "...", "amount_mxn": 200, "paid": false } ] } ]

# 401 -> refresh once, then re-auth. The customer-loans payload carries
# third-party personal data, so retention is scoped under LFPDPPP.
      

Consent under Mexico's Ley Fintech

The governing instrument is the Ley para Regular las Instituciones de Tecnología Financiera, enacted in 2018. Its Article 76 establishes the open-finance mandate, and supervision sits with the CNBV and Banco de Mexico, with the Finance Ministry holding primary interpretation. The law splits data into open, aggregated and transactional categories, the last requiring user consent. Secondary rule-making for transactional-data sharing is still being worked through in Mexico, so we do not assert specific thresholds or windows as settled; the regulated path is treated as an upgrade, not a present guarantee.

Ximple's structure adds a consent wrinkle that is specific to this app. The Aliado consents for their own line, but the customer sub-loan ledger holds records of people who are not the consenting user. We treat that payload as third-party personal data under the LFPDPPP, minimize it to what the integration needs, keep consent and access logs, and operate under an NDA where the engagement calls for one. Authorized, documented, consented access is how the studio works, full stop.

What this build has to account for

Specifics we plan around on Ximple, written as things we handle:

• We model the Aliado line and the downstream customer sub-loans as separate ledgers joined by an explicit parent-child link, so a repayment on a customer loan is never mis-applied to the Aliado's own balance.
• We collapse cash-network pickups and Mastercard-card disbursements into one event type with a rail tag, because the company expanded its payout network from roughly 15,000 to a stated 75,000+ locations and reporting that silently mixes the two rails double-counts a single disbursement.
• Because the product is still adding rails — the disbursement card launched in early 2025, per LatamFintech — we schedule a periodic contract check so a renamed screen or field surfaces in our test run before it reaches your pipeline.
• Access is arranged with you at onboarding; the build runs against a consenting Aliado account or a sponsor sandbox, and the customer-data retention rules are designed in from the first read rather than bolted on.

Integrations Aliado-facing teams ask for

• A distribution brand reconciling which Aliados financed its merchandise: the merchandise-loan application feed joined to disbursement events by supplier reference.
• An accounting or ERP sync pulling the Aliado's working-capital balance and repayment schedule on a cycle so the books reflect live exposure.
• A credit-data partner ingesting the consented customer sub-loan ledger to build repayment history for borrowers with thin files — the financial-inclusion case the company itself describes.
• A treasury view merging cash-network and card-rail disbursements into one cash position with the rail preserved for audit.

Screens we walked through

The store screenshots we reviewed while mapping the surfaces above. Click to enlarge.

Sources behind this mapping

Mapped in May 2026 from the app's own store description and screenshots, plus public reporting on the company's funding, structure and product roadmap. Primary sources opened: LatamFintech's report on the seed round and platform launch (seed round and platform), LatamFintech's coverage of the Mastercard/Dock disbursement card (disbursement card), and the Google Play listing for the developer and identifiers (co.ximple listing). Figures attributed to those reports are stated as reported, not as independently audited facts.

Mapped by the OpenBanking Studio integration desk · May 2026.

The wider tiendita-credit layer in Mexico

Same-category apps an integrator often wants under one schema. Listed for ecosystem context, not ranked.

• Yofio — working-capital credit for corner shops, underwriting from store photos; holds merchant credit lines and inventory-purchase records.
• Tienda Pago — inventory financing tied to distributor deliveries; holds short-term credit and repayment data for small shops.
• Konfío — SME credit, a business card and payment terminals; holds loan, card and merchant-transaction records.
• Clip — card-acceptance for micro-merchants; holds payment-acceptance and settlement data.
• iBasto — B2B ordering with embedded credit for tienditas; holds order and trade-credit ledgers.
• KiWi — payments and credit for small merchants; holds transaction and credit-line data.
• Mercado Crédito — the lending arm inside Mercado Libre; holds seller and consumer credit lines and repayment history.
• R2 — embedded lending distributed through platforms; holds revenue-based loan and repayment records for small businesses.

Questions integrators of Ximple raise

Ximple splits credit between the Aliado and the Aliado's own customers. Can those two ledgers be pulled apart?

Yes. We model them as a parent line and child sub-loans with an explicit link, so a customer repayment never lands on the Aliado's own balance. Each ledger keeps its own balance, schedule and status fields in the delivered client.

Which Mexican regulator governs sharing Ximple account data?

Mexico's Ley Fintech, enacted in 2018, places open finance under the CNBV and Banco de Mexico, with the Finance Ministry interpreting it. The Article 76 mandate exists, but secondary rules for transactional-data APIs are still maturing, so for now we work through user-consented interface integration and treat the regulated path as the later upgrade.

Cash-network pickups and the Mastercard disbursement card are different rails. How is that represented?

Both become one disbursement event type carrying a rail tag (cash_network or mastercard_card) plus location and timestamp. Keeping a single shape but tagging the rail stops reporting from double-counting one disbursement.

Does reading an Aliado's customer loan records create a third-party data obligation?

It does, because those borrowers are not the consenting Aliado. We scope retention and minimization of that payload under Mexico's LFPDPPP, keep consent records, and ship retention guidance next to the code.

A working Ximple client — Aliado profile, both credit ledgers, disbursement events tagged by rail, and the repayment schedule — typically lands in one to two weeks. You can take it as runnable source plus the OpenAPI spec and the auth-flow report, from $300, invoiced only after delivery once you have checked it against a live account; or skip the build and call our hosted endpoints instead, paying per call with nothing upfront. Give us the app name and what you need from its data at /contact.html and we will scope it back to you.