Pulling the loan-ledger and repayment data out of Noro Préstamos

Up to $35,000 MXN per loan, 91–180 day terms, disbursed by SPEI straight to the borrower's CLABE — Noro Préstamos keeps that whole ledger, the VIP-cashback counter, and the installment history behind a phone-number login that never exports on its own. A bookkeeping tool, a collections-and-reminders platform, or a debt-aggregation product that wants to pull this in has to come through the same surface a borrower does. That is the surface we wire up.

What sits behind the borrower login

The app names its own pieces fairly directly. We have mapped what the user sees in the screens against what the underlying mobile traffic carries.

Files the app collects from the device — INE photograph, selfie liveness frame — are deliberately excluded from the default integration deliverable unless the customer's use case explicitly calls for them and the consent text is rewritten to cover it.

Consent and the Mexican regulatory footing

Mexico's 2018 Ley Fintech wrote open finance into Article 76 and told CNBV and Banxico to issue the secondary rules. Eight years on, the only secondary regulation actually in force covers ATM open data; transactional data sharing has no binding rules, no mandated APIs, no accredited TPP register. Entrepreneurs filed an amparo against CNBV, Banxico and SHCP in January 2026 over the delay. The practical effect for a SOFOM-shaped consumer lender like Noro is straightforward: there is no regulator-blessed rail you can plug into. The dependable basis for the integration is the consent of the person — or the operator — whose data you are pulling.

We design the consent flow around that. Scope is enumerated per data domain in the table above, the borrower can revoke from the consenting account, and access tokens carry an explicit expiry so a forgotten integration cannot quietly keep reading. CAT (Costo Anual Total) values and contract terms surfaced through the integration are passed through unaltered — they are the lender's disclosure, not ours to recompute. NDA, processing agreement, and a data-retention schedule are part of the engagement when the customer is a regulated counterparty.

How we actually reach the data

Two routes carry the work, picked per project rather than offered as a buffet.

Route A — authorized protocol capture under user consent

The borrower app talks to a backend at npplus.net-adjacent hosts. We capture the auth handshake, the OTP exchange, the loan-ledger endpoints and the repayments stream against a consenting account, then write a thin client that mirrors what the device does. Coverage is whatever the borrower themselves can see in the app, which is the entire integration target above. Effort is moderate — Mexican loan apps churn UI faster than backend, so the contract surfaces stay relatively stable. Durability depends on rebuilds; we keep a captured app build pinned so the binding has a fixed reference.

Route B — operator-sponsored sandbox

When the customer is Noro itself, a partner, or a B2B counterparty with a sponsor letter, we arrange a sandbox or test-cohort access with the operator and build against that. Coverage broadens (back-office endpoints, bulk export) and the resulting code is durable across app rebuilds because we hold to the documented contract. We handle the introduction; the customer does not have to negotiate this in advance of engaging us.

For most callers — a bookkeeping or PFM product that wants the borrower's data with the borrower's permission — Route A is the right answer and the one we recommend by default. Route B is the better choice when the volume is institutional and the latency budget is in milliseconds.

What ships with the build

• OpenAPI 3.1 specification for the normalized borrower surface — profile, applications, active loan, installments, repayments, cashback, notifications.
• Runnable source in Python (httpx + pydantic) and Node.js (undici + zod), with the auth handshake, OTP exchange, and pagination already wired.
• Protocol and auth-flow report: the OTP request, the bearer-token shape, the refresh window we observed, where the app pins certificates, and what the device fingerprint header expects.
• A normalized webhook payload for repayment events that unifies the SPEI and convenience-store channels onto the same installment id.
• Replayable test fixtures (recorded over a consenting test account, scrubbed of personal data) and an integration test suite that runs against them in CI.
• Operator-facing notes: a data-retention proposal and the consent copy you can paste into your own onboarding to cover what the integration touches.

Shape of the delivered borrower client

Illustrative — exact paths and headers are confirmed during the build against the live client and pinned to a captured app build, not promised in advance.

import httpx
from typing import Optional

class NoroClient:
    BASE = "https://api.npplus.net"  # host confirmed during the build

    def __init__(self) -> None:
        self._http = httpx.AsyncClient(
            timeout=15.0,
            headers={
                "User-Agent": "NoroAndroid/",
                "X-Device-Id": "",
            },
        )
        self._token: Optional[str] = None

    async def request_otp(self, msisdn: str) -> str:
        r = await self._http.post(
            f"{self.BASE}/v1/auth/otp/request",
            json={"phone": msisdn, "country": "MX"},
        )
        r.raise_for_status()
        return r.json()["request_id"]

    async def verify_otp(self, request_id: str, code: str) -> None:
        r = await self._http.post(
            f"{self.BASE}/v1/auth/otp/verify",
            json={"request_id": request_id, "code": code},
        )
        r.raise_for_status()
        self._token = r.json()["access_token"]
        self._http.headers["Authorization"] = f"Bearer {self._token}"

    async def active_loan(self) -> dict:
        # Single active line; includes principal, fee, VAT, installment schedule.
        r = await self._http.get(f"{self.BASE}/v1/borrower/loan?include=schedule")
        r.raise_for_status()
        return r.json()

    async def repayments(self, since_iso: str) -> list[dict]:
        r = await self._http.get(
            f"{self.BASE}/v1/borrower/repayments",
            params={"since": since_iso},  # SPEI + convenience-store events combined
        )
        r.raise_for_status()
        return r.json()["events"]

Things we account for on this build

These are not warnings to the customer. They are choices the studio makes on the way in.

• Operator-name vs. SIPRES-name mismatch. The brand "Noro Préstamos" did not surface an active CONDUSEF entry in the third-party review we read; SOFOM ENR lenders in Mexico routinely operate under a different legal name from their marketing brand. We resolve the live registered entity during onboarding and write that entity, not the brand, into the consent copy and the audit logs.
• Two repayment channels, one ledger. SPEI repayments arrive in seconds; convenience-store cash receipts arrive a few minutes behind, sometimes hours. We key both on installment id and normalize them so a downstream collections workflow does not double-count or skip.
• App-build drift. Mexican lending apps ship frequently; backend contracts tend to outlive UI rewrites but not always. The client is pinned against a captured app build, and the support agreement schedules a recurring binding check whenever a new release lands.
• Sensitive media handling. The borrower flow uploads INE photographs and selfie liveness frames. Default builds exclude this from the integration surface. When a project genuinely needs it, we move it into a separate, narrower endpoint with its own consent string and shorter retention.
• Disclosure pass-through. CAT, service fee and VAT figures are surfaced verbatim from the lender's own response; we do not recompute them in the delivered code, because the lender's disclosure is the regulated artifact.

The integration jobs that actually show up

• Bookkeeping sync for a small-business borrower. Active loan + installment schedule into a Mexican accounting tool, so the founder's books reflect the debt without manual entry.
• Debt aggregator dashboard. One borrower's exposure across Noro and the other lenders they use, with installment dates and remaining balance unified.
• Collections-and-reminders SaaS. The repayments webhook feeding a reminder cadence that backs off the moment a payment lands.
• Underwriter assist. Anonymized loan-application outcomes (decision, decline reason, amount) routed to a partner's scoring model for back-testing, under a Route B engagement with the operator.

Price and timing

$300 covers source-code delivery for the borrower-side endpoints described above — paid after the build clears your review, never up front. The hosted alternative bills only on the calls you actually make, with no upfront commitment, useful when you want someone else to carry the keep-the-lights-on work. Delivery cycle is one to two weeks from the moment a consenting test account or sponsor credential is in hand; arranging that access is our step, not yours. Send the requirements to /contact.html and we'll come back with a scope and a fixed delivery date.

Borrower screens we worked from

The interface evidence the mapping is built against:

Questions an integrator usually asks

Does Noro publish a SIPRES record we can lean on for regulator validation?

The reviews we checked could not find an active CONDUSEF SIPRES entry under the Noro Préstamos brand name; the operator appears to file under a different legal entity, as is common for SOFOM ENR-shaped lenders in Mexico. We confirm the live entity for your project during onboarding and design the consent and disclosure copy against whatever it actually is, not what the marketing says.

Will the integration survive when Noro pushes a new app build?

Endpoints behind the borrower app drift when the operator changes versions, especially for a fast-moving Mexican lender. We pin the client to a captured app build, schedule a recurring binding check inside the support agreement, and refresh the bindings when a new release breaks them. Most months nothing changes; when something does, the test suite catches it before your traffic does.

Can repayment events from OXXO cash and SPEI bank transfers land in one webhook stream?

Yes. The borrower-facing endpoints expose both channels with the same installment-id key, so we normalize them into a single repayments feed in the delivered code. Convenience-store receipts arrive a few minutes behind the cash; SPEI lands in seconds. The webhook payload carries the channel as a field so your downstream can branch on it without re-querying.

Sources we checked

Cross-checked against the in-app disclosure text in the Play Store listing, an independent Mexican review of Noro Préstamos' regulatory standing, Banxico's own SPEI reference, and current commentary on the stalled state of Mexican open-finance secondary rules.

• Google Play — Noro: Prestamos de Dinero listing
• Prestamosenlineaconfiables.com — Noro Préstamos: regulatory and CONDUSEF review
• Banco de México — SPEI reference
• Open Banking Tracker — Mexico: eight years on, still waiting

Other Mexican lending apps with similar data shapes

Same category in the Mexican market, broadly comparable borrower-side data. Plain names; no claim about relative quality.

• Kueski. Short-term consumer credit with an installment schedule and a borrower portal. Unified Kueski-plus-Noro pulls give a fuller picture of a borrower's short-term obligations.
• Moneyman. Up to about $25,000 MXN; a borrower app with active-loan and history screens that map cleanly onto the same normalized surface.
• AvaFin. Higher-limit consumer loans for established credit; similar repayment and statement data, lower turnover.
• Credilikeme. Tiered borrower progression with a referral counter; integration shape mirrors Noro plus a loyalty-style domain.
• Kubo Financiero. CNBV-supervised SOFIPO — longer-tenor loans with the same installment-ledger structure but stricter consent paper.
• DiDi Préstamos. Loans embedded in the DiDi driver app; ledger and repayment events live behind a platform login rather than a standalone identity.
• Tala. Bureau-free underwriting in Mexico; alternative-data signals plus the standard installment-and-repayment surfaces.
• MexDin. Comparable bureau-free short-term lender; same SPEI-and-convenience-store repayment pattern.