Syncing Noro Préstamos loan, repayment and cashback data

Every approved Noro loan ends with a SPEI transfer to a borrower's 18-digit CLABE, and every repayment — by SPEI or paid in cash at a convenience store — lands back against that same balance. That is the shape of the data worth integrating here: a small set of per-borrower records that change frequently and in near real time. We pull them on a polling cycle that advances a cursor each pass, so a downstream ledger, BNPL underwriter, or collections dashboard stays a few seconds behind the app rather than a day.

The route we lean on is user-consented interface integration: with the borrower's authorization, we map the JSON surfaces behind Noro's loan screen, repayment schedule and cashback view, then ship a client that reads them on a schedule. Where Noro's backing entity participates as a regulated financial institution, the same data can later be reached through Mexico's open-finance channel — that part is treated as a forward-looking option below, not as today's foundation.

What Noro keeps for each borrower

The app describes a tight product: amounts up to $35,000 MXN, terms from 91 to 180 days, a maximum APR of 36% and a service fee plus IVA on top (per its Play Store listing). The data that backs that product breaks down like this.

Routes into the data

Three routes genuinely fit Noro. They differ in what is reachable, how much standing-up they need, and how long they hold once built.

Consented interface integration

With the borrower's authorization, we instrument the phone-number login (an OTP exchange that returns a short-lived session token) and map the endpoints that feed the loan, repayment and cashback screens. This mirrors exactly what the borrower sees, it covers every domain in the table above, and it is the quickest to a working client. It follows app changes, so we account for re-mapping as part of maintenance. We arrange the access during onboarding — a consenting test account or the borrower's own session, set up with you.

Bank-side reconciliation over SPEI / CLABE

Because disbursements and repayments by transfer touch the borrower's bank CLABE, account aggregation of that linked bank account can reconstruct the money movements independently of the app. It will not see cashback tier or the app's internal score, but it is durable and bank-grade for the cash flows. Useful as a cross-check or where app-side access is constrained.

Regulated open-finance consent

Ley Fintech obliges financial entities to share data through APIs, and the transactional-data layer is the eventual home for a read like this. The binding technical standard is still being rolled out by the CNBV and Banxico, so we treat this as the channel to migrate onto later rather than the one to depend on now.

For most teams the consented interface route is the spine of the build, with bank-side reconciliation wired in as a verification layer for the SPEI cash flows. We would scope it that way and revisit the regulated channel once its standard binds.

Polling the repayment ledger

The core loop is a delta read: authenticate, ask for everything since the last cursor, persist the new cursor. A sketch of the repayment pull, with field names confirmed during the build:

# Delta sync of a borrower's Noro loan + repayment ledger.
# Auth is a phone-number OTP exchange that returns a short-lived
# session token; the poller advances a server cursor each cycle.

import requests

BASE = "https://api.npplus.net"          # host confirmed during the build
SESSION = "..."                          # token from the OTP login exchange

def pull_repayments(loan_id, cursor):
    r = requests.get(
        f"{BASE}/v1/loans/{loan_id}/repayments",
        params={"since": cursor, "limit": 100},
        headers={"Authorization": f"Bearer {SESSION}"},
        timeout=15,
    )
    if r.status_code == 401:             # token expired -> re-run OTP exchange
        raise SessionExpired
    r.raise_for_status()
    body = r.json()
    for ev in body["items"]:
        # channel is "SPEI" or "CONVENIENCE_STORE"; amounts in MXN
        record(loan_id, ev["paid_at"], ev["amount_mxn"],
               ev["channel"], ev["spei_ref"])
    return body["next_cursor"]           # persist for the next poll

Field and path names above are illustrative of the shape we confirm against a live session, not a published contract. The same pattern reads the loan summary and the cashback ledger off their own cursors so the three streams stay independent.

What you get back

The deliverable is code that runs, not a slide deck. For Noro that means:

• Runnable client source in Python and Node.js for the OTP login, the loan-summary read, the repayment delta sync and the cashback-ledger read.
• A poller with cursor persistence and back-off, so the sync resumes cleanly after an outage instead of replaying the whole history.
• An automated test suite running against recorded fixtures of the loan, repayment and cashback responses.
• A normalized schema that separates principal, fee/IVA breakdown, payment events and rewards into clean tables.
• An OpenAPI description of the mapped surfaces and a short auth-flow report covering the OTP-to-token chain.
• Interface documentation plus data-retention and consent-handling notes for the borrower data you ingest.

Consent, and how Mexico's rules apply

The basis the integration stands on is the borrower's own authorization to access their account and move their data — captured, time-boxed and revocable, with each access logged. Ley Fintech (2018) frames open data, aggregated data and consented transactional data sharing under the CNBV and Banco de México; the transactional layer that would carry a read like this is still being phased into binding form, so it is where the integration can migrate, not what it relies on today.

Two consumer-side regimes shape how we handle the data. Lenders of this kind typically operate as a SOFOM E.N.R. under CONDUSEF, which carries CAT (Costo Anual Total) disclosure and contract-transparency duties — relevant because the fee and IVA fields we map are the same numbers those disclosures rest on. Personal data is governed by the LFPDPPP, Mexico's data-protection law, so we keep the integration data-minimized to the fields the borrower authorized, hold an NDA where the engagement needs one, and avoid pulling identity data the downstream system has no use for.

What the build has to get right

A few things about Noro specifically shape the engineering, and we handle each as part of the work.

Two repayment channels, one balance

Repayments arrive by SPEI in seconds and by cash at convenience stores with a clearing lag. We reconcile both against a single outstanding balance keyed to the loan id, so a cash payment that clears hours later does not look like a missed instalment or get counted twice.

The fee stack is decomposable

Noro's representative example splits a loan into principal, interest, a service fee and IVA at 16% (as the app states it). We decompose each payment the same way rather than storing a lump total, because a downstream accounting or collections system needs the components, not just the amount due.

Cashback is its own stream

On-time payments accrue VIP cashback and nudge an internal score. We model that ledger as a separate delta stream from the loan itself, so rewards never get mistaken for principal repayment and the score history stays auditable on its own.

Where teams plug it in

• A collections or servicing tool that needs each borrower's live balance and the next due date, refreshed continuously rather than imported overnight.
• A repeat-borrower risk model that wants the on-time-payment signal and internal score movement to re-price a second loan.
• A reconciliation job that matches Noro's SPEI disbursements and repayments against the bank CLABE statement to confirm money actually moved.
• A rewards or retention system that reads the VIP cashback ledger to trigger offers for borrowers approaching a tier.

Screens we worked from

The Play Store screenshots below informed the surface map. Click to enlarge.

How this mapping was put together

This page reflects a read of Noro's public listing and the regulatory ground it sits on, checked on 15 June 2026. The product terms come from the app's own Play Store description and its operator site at npplus.net; the rail behaviour from Banco de México's SPEI documentation; the regulatory status from the Ley Fintech open-finance tracker for Mexico. Specific figures are attributed to those sources and not asserted beyond them.

• Noro: Prestamos de Dinero — Google Play listing
• Noro Préstamos privacy notice (npplus.net)
• Banco de México — SPEI overview
• Open Banking Tracker — Mexico open finance / Ley Fintech

Mapping compiled by OpenFinance Lab · 2026-06-15.

Other Mexican lending apps in the same orbit

Teams that integrate Noro usually want the same view of its peers. Each of these holds comparable per-borrower data and would slot into a unified lending integration.

• Kueski — one of the earliest instant micro-loan apps in Mexico; holds loan lines, repayment schedules and disbursement records per borrower.
• Moneyman — short-term personal credit with first-loan offers; keeps application, balance and repayment history.
• AvaFin — installment personal loans with larger limits; per-user credit lines and payment records.
• Credilikeme — small loans with a points-and-levels layer; a loan ledger plus a rewards mechanic comparable to Noro's cashback.
• Vivus — single-payment short-term loans; borrower profile, due dates and outstanding balance.
• Crédito365 — quick small-ticket loans; application records and repayment tracking.
• Kubo Financiero — regulated lending and savings; account balances, loan accounts and transaction history.
• Súper Dinero — personal loans settled through convenience-store networks; loan and repayment records tied to cash repayment.

Questions integrators ask about Noro

Noro pays out over SPEI — can the integration pick up a disbursement the moment it settles?

Yes. SPEI settles in seconds and runs around the clock, so the sync advances its cursor on settlement events rather than waiting for a nightly batch. A disbursement to the borrower's CLABE shows up in the feed on the next poll, with the SPEI reference and amount attached.

Repayments come in by SPEI and at convenience stores — how does the delta sync keep both reconciled?

Both channels post against the same outstanding balance, so we key each event to the loan id and a server cursor. Cash-network payments arrive with a short clearing lag; the poller picks them up on the cycle after they clear and reconciles them to the schedule without double-counting.

Noro approves without a bureau check — does that change what identity data is available to map?

It does. The borrower profile is assembled from the INE, a Mexican phone number and the receiving CLABE rather than a bureau file, so the integration maps those fields directly and keeps to what the consented borrower has authorized — nothing past that.

Mexico's open-finance rules are still being phased in — what does the integration actually depend on?

The dependable basis is the borrower's own authorization. Ley Fintech's transactional data-sharing provisions are the direction of travel under the CNBV and Banxico, but the binding technical standard is still being rolled out, so we build on consented access today and leave room to switch onto the regulated channel as it lands.

Getting the Noro integration built

Source-code delivery starts at $300, billed only after the working integration is in your hands and you are satisfied with it. The other path skips the build fee entirely: call our hosted endpoints and pay per call. Turnaround is one to two weeks for a first drop, and access — a consenting test account or the borrower's own session — is arranged with you during onboarding. Tell us the app name and what you want out of Noro's data on the contact page and we will scope the route.

Last checked 2026-06-15