Reaching a Mano Préstamo borrower's loan and repayment state from your own code

Pulling a borrower's loan into your own stack

A Mano Préstamo account holds one borrower's whole loan lifecycle — the requested amount, the approved principal and term, the amortization schedule, and each repayment as it posts. The app runs in Peru on soles, onboarding people with a DNI national ID, a phone number, and a bank account in their own name. None of that state sits in a file you can download; it lives behind the borrower's authenticated session. The work here is to stand up a language client that signs in as the consenting borrower and reads that state cleanly, then keeps it fresh as installments come due.

We lead with the runnable client, not a document. The first thing that lands is a Python and Node.js SDK that authenticates against the app's own surfaces, lists the active and historical loans, walks the cuotas (installment) schedule, and reconciles the disbursement against the borrower's bank account. The bottom line for routing: there is no open-finance rail to ride in Peru yet, so the dependable basis is the borrower's own consent, and the dependable method is authorized analysis of the app's traffic under that consent.

What the app keeps per borrower

These rows track what the app actually surfaces to a logged-in borrower, named the way Mano Préstamo presents it where we could see it.

Ways into that data, and the one we take

Authorized protocol analysis under the borrower's consent

The borrower authorizes the work; we map the app's client-to-server exchange — the phone/DNI sign-in and token handling, the loan list, the cuotas schedule, the disbursement lookup — and rebuild those calls as a clean client. This reaches everything a borrower can see in-app. Effort is moderate and front-loaded into the mapping. Durability is good between app releases and is maintained by re-checking the captured surfaces when the app ships a new version. Access is arranged with you during onboarding, against a consenting account.

User-consented session access

A thinner variant for teams that only need a periodic read: the borrower consents, we drive their authenticated session on a schedule and hand back the normalized records without standing up the full SDK. Lower effort, less flexible, fine for a recurring export of one portfolio.

Bank-side reconciliation (forward-looking)

The disbursement and repayments touch the borrower's bank account over Peru's interbank rails. Today that reconciliation runs off the borrower's own bank records or statement, matched by CCI and amount. When the SBS open-finance model moves from roadmap to a working rail, this leg can shift onto a regulated bank-data consent without changing the loan-side client.

We would run the first route as the backbone and treat bank-side matching as a bolt-on where a client needs payout confirmation. It reaches the most, it is the most stable to maintain, and it does not wait on a regulation that has not landed.

What lands in your repo

• A runnable Python + Node.js client. Authenticates as the consenting borrower, lists loans, returns the cuotas schedule and repayment states, and exposes the disbursement record — typed objects, not raw blobs.
• A sync layer. A cursor/delta poller over the schedule that upserts each installment by id, so a re-poll refreshes state in place rather than appending duplicates, plus handlers for any status callback the app emits on a payment or payout.
• An automated test suite. Fixtures captured from real responses and contract tests against the normalized shape, so a field rename in a new app build shows up as a test diff to fix.
• A normalized schema + interface documentation. The loan/schedule/disbursement model in plain terms, with the field mapping from the app's own names.
• Supporting specs, secondary. An OpenAPI description of the reconstructed surface, a protocol and auth-flow write-up of the token chain, and a short data-retention and consent-handling note sized to Ley 29733.

A repayment-schedule pull, sketched

Illustrative, in the shape of the client we hand over — field names follow the app's Spanish vocabulary and were confirmed against captured traffic during the build.

from manoprestamo_client import BorrowerSession   # shipped in the SDK

# Borrower consents once during onboarding; the phone + DNI OTP
# is exchanged for a session we drive on their behalf.
sess = BorrowerSession.from_consent(consent_token)

loan = sess.active_loan()                  # GET /v1/prestamos/activo
print(loan.principal_pen, loan.term_days, loan.status)
#      2000.0              120             "vigente"

# Interest and the service fee are quoted as separate lines.
print(loan.interes_pen, loan.comision_pen, loan.total_pen)
#      168.0             20.0              2168.0

for cuota in loan.schedule():              # GET /v1/prestamos/{id}/cuotas
    print(cuota.numero, cuota.vence, cuota.monto_pen, cuota.estado)
    #     1            2026-06-01   542.0           "pagada"
    #     estado in {"pendiente", "pagada", "vencida"}

pay = loan.disbursement()                  # GET /v1/prestamos/{id}/desembolso
reconcile(pay.cci, pay.monto_pen, pay.acreditado_en)   # match on the bank rail

# Consent can be withdrawn at any time under Ley 29733.
if not sess.consent_valid():
    sess.stop_and_purge(loan.id)

The shape we normalize to

Two short records, currency in ISO PEN, identity reduced to a consented reference rather than the raw DNI.

{
  "borrower_ref": "cons:9f1c…",          // hashed, never the bare DNI
  "loan": {
    "id": "ln_88421",
    "principal_pen": 2000.0,
    "term_days": 120,
    "interest_pen": 168.0,
    "service_fee_pen": 20.0,
    "total_pen": 2168.0,
    "status": "vigente",
    "opened_at": "2026-05-02"
  },
  "schedule": [
    { "n": 1, "due": "2026-06-01", "amount_pen": 542.0, "state": "pagada" },
    { "n": 2, "due": "2026-07-01", "amount_pen": 542.0, "state": "pendiente" }
  ],
  "disbursement": { "cci": "002-193-…", "amount_pen": 2000.0, "posted_at": "2026-05-02T14:11:00-05:00" }
}

Consent and the Peru rulebook

Mano Préstamo's per-borrower data is personal financial data, so the operative law is Peru's Personal Data Protection Law, Ley 29733. Its updated regulation — Supreme Decree 016-2024-JUS, in force since 30 March 2025 per Peru's data-protection authority — requires informed, express, and unequivocal consent, lets the subject withdraw it freely, and added an explicit right to data portability. That consent is the dependable footing the integration stands on, and our consent records and access logs are built to evidence it.

Open finance itself is not yet a rail you can plug into here. The SBS stood up a dedicated Open Finance department and has been working a roadmap with World Bank support, with publication signalled for around the end of 2025, but no binding open-finance obligation is in force as of this writing. We treat it as the direction of travel, not current law: the build runs on the borrower's consent today and can move onto a regulated rail if and when one is published. Separately, the BCRP's payment-interoperability mandate already links Peru's wallets and bank accounts across the CCE, which is what makes disbursement reconciliation by CCI realistic. Access is minimized, logged, and covered by an NDA where a client needs one.

What we account for in the build

Two specifics on this app shape how the client is written, and we handle both rather than passing them to you as conditions.

• The fee-plus-interest split. The listing quotes interest and a separate service fee as distinct charges — its worked example is 168 soles of interest plus a 20-sol fee on a 2,000-sol loan, repaying 2,168. A blended rate would not reconcile against the contract, so the model carries interest and fee as separate fields and ties them to the total repayable.
• Disbursement timing against operating hours. The app deposits to the borrower's bank account during business hours, which the listing gives as Monday to Saturday, 9:00 to 18:00. We window the reconciliation job to that schedule and treat the gap between an approved loan and a posted deposit as expected, so a not-yet-credited loan is held as pending rather than flagged as failed.
• Consent withdrawal as a first-class path. Because Ley 29733 lets a borrower revoke at any time, the client checks consent before each pull and stops cleanly, and the retention note covers purging cached loan and repayment rows on revocation.

Other Peru lending apps in the same space

If a single integration is meant to span several Peruvian cash-loan apps, these come up in the same category. Each holds a comparable per-borrower loan and repayment ledger behind its own login, which is why one normalized model can sit over the set.

• Apurata — fully online personal loans in Peru; holds application status, approved terms, and a repayment ledger per user.
• Solventa — online personal-credit requests for Peruvian borrowers, with loan and installment records behind the account.
• YanaCash — a Peru digital-lending platform offering personal credit; keeps per-borrower loan and repayment state.
• Kashin — short-ticket loans for Peruvian users; holds small-amount loan contracts and schedules.
• Alpacash — instant credit aimed at Peruvian households, with loan amounts and repayment tracking per account.
• Hola Andy — fast online loans in Peru; carries application, approval, and repayment records.
• iKori — a licensed Peru lender's app, holding regulated loan accounts and installment data.
• Hicredito — quick personal loans for Peruvian users, with per-borrower loan and schedule records.

Framing only — no ranking, and each app's data stays inside its own consented integration.

Screens we worked from

Store screenshots used to orient the surface map. Tap to enlarge.

Questions integrators ask us about Mano Préstamo

Can the client keep a borrower's repayment schedule in sync as installments post?

Yes. The shipped client does a cursor poll over the cuotas (installment) surface, windowed to the app's Monday–Saturday operating hours when postings actually move, and upserts each installment by its id so a re-poll updates state in place rather than appending duplicates. If the app emits status callbacks for a posted payment or a disbursement, we wire those in and fall back to the poller for everything else.

Does this ride Peru's open finance rules?

No. Peru's open-finance model is still at the roadmap stage with the SBS, which set up a dedicated Open Finance department but has not put binding rules in force. The route we ship runs on the borrower's own informed, express consent under Peru's Personal Data Protection Law (Ley 29733), whose 2024 regulation already grants a data-portability right. If a regulated rail lands later, the same client can move onto it.

How do you handle the interest versus service-fee split?

The listing quotes interest and a separate service fee as distinct lines — its worked example is 168 soles interest plus a 20-sol fee on a 2,000-sol loan. We model both as separate fields and reconcile them to the total repayable, so your ledger matches the app's contract rather than a blended rate.

What happens to cached records if a borrower withdraws consent?

Ley 29733 lets a borrower revoke consent at any time. The client checks consent validity before each pull and stops cleanly when it is gone, and the retention note we deliver covers deleting or tombstoning the cached loan and repayment records on revocation.

How this brief was put together

Checked on 8 June 2026 against the app's own store listing for product terms and onboarding, and against primary regulatory sources for the Peru picture: the BCRP's payment-interoperability paper for the bank-rail context, Peru's data-protection regulation for consent and portability, and SBS coverage for the open-finance roadmap status. Figures attributed to the listing are stated as the app describes them, not independently audited.

• Mano Préstamo on Google Play — product terms, onboarding, contact.
• BCRP — Peru's Retail Payments Interoperability Strategy — CCE rails and wallet interconnection.
• New regulation of Peru's Personal Data Protection Act (DS 016-2024-JUS) — consent and portability.
• SBS roadmap and principles for Peru's open-finance model — current regulatory status.

OpenFinance Lab — interface engineering notes · 2026-06-08.