Connecting to Tucambista's exchange operations and live rates

Every Tucambista operation is a two-leg bank transfer: soles or dollars go in, the converted currency lands back in a registered account, and per its own store listing that round trip settles in under fifteen minutes. The integration question is not the rate painted on the home screen. It is whether your systems can see each operation as it happens — the rate that was actually locked, the amounts on both legs, the bank reference, and the moment the money cleared. That movement is what this brief is about.

The bottom line is short. Tucambista holds a real per-account ledger of currency conversions plus a live rate feed, and a business that pays suppliers, books FX gains, or compares exchange houses wants both. Because Peru has no open-banking consent framework in force, the route that returns the most fidelity is authorized interface integration against an account the client controls, with the operation receipt as a cheap second source for reconciliation.

What sits behind a Tucambista login

These are the surfaces an integrator would actually map, named the way the app presents them where that is known.

Routes to the operation and rate data

Four routes apply here. They differ in fidelity, effort, and how long they hold up.

1 · Authorized interface integration (recommended)

We map the authenticated traffic the mobile client itself uses — login and token refresh, the rate quote, operation creation, the operations list, and the status lookup. This sees exactly what a logged-in user sees, including the rate that was locked and the settlement reference. Effort is moderate: one client to analyse, then a stable adapter. Access is arranged with you during onboarding and the build runs against a consenting Tucambista account, not a guessed schema.

2 · User-consented credential access

The integration operates inside a real account the client owns and authorizes. Reach equals what that user can do; durability follows how the session and login behave. This is a good fit for a pilot or a low-volume corporate flow before a wider rollout.

3 · Native operation-receipt export (fallback)

Tucambista issues a constancia per completed operation, in-app and by email. That gives the final amounts, the applied rate and the bank reference at high reliability but only after settlement, with no live quotes. It is a low-cost reconciliation backstop, not a primary feed.

4 · Regulated open-finance consent (future)

Peru's SBS has signalled a phased open-finance approach with a roadmap expected around the end of 2025 per the regulator's own statements, rather than a consent regime in force today. There is no consent endpoint to call now. We build the interface adapter so that a future SBS scheme can slot in behind the same internal model without a rewrite.

For most teams the first route is the one that earns its keep: it captures the locked rate and the settlement reference, and it does not wait on anything being published. The export route rides alongside it as a quiet check that the numbers agree.

What the build hands over

The deliverable is tied to Tucambista's real surfaces, not a generic kit:

• An OpenAPI specification covering the rate quote, operation create, operation list and operation detail calls, with the auth flow documented.
• A protocol and auth-flow report: the login token, refresh behaviour, and the device headers the mobile client sends.
• Runnable source for the key endpoints in Python and Node.js — quote, create, poll-to-settled, list history.
• Automated tests, including the rate-expiry and the awaiting-deposit → settled state path.
• Interface documentation plus data-retention and consent-logging guidance scoped to Peru's rules.

A worked example: quote, operation, settlement

Shapes below are illustrative and confirmed against a consenting account during the build, not assumed. Authentication is a bearer token issued at login and refreshed on expiry; mobile requests also carry device headers.

# 1. Authenticate. Token short-lived; refresh on 401.
POST /auth/login
{ "doc_type": "DNI", "doc_number": "********", "password": "********" }
-> 200 { "access_token": "<jwt>", "refresh_token": "...", "expires_in": 900 }

# 2. Current rate for the pair (compra = buy, venta = sell).
GET /rates?from=USD&to=PEN
-> 200 { "buy": 3.7xx, "sell": 3.7xx, "quoted_at": "...", "valid_for_s": 90 }

# 3. Create an operation. The applied rate is locked server-side and
#    the quote expires if the inbound transfer is not funded in time.
POST /operations
{ "side": "sell_usd", "amount_usd": 1000,
  "credit_account_id": "<registered PEN account>" }
-> 201 { "operation_id": "...", "rate_applied": 3.7xx,
         "amount_pen": 37xx.00, "status": "awaiting_deposit",
         "rate_expires_at": "..." }

# 4. Reconcile. Poll until the outbound leg clears, then capture the
#    bank reference so it matches the account statement line.
GET /operations/{operation_id}
-> 200 { "status": "settled", "bank_reference": "...",
         "settled_at": "...", "debit_account": "...",
         "credit_account": "..." }
      

Where this gets wired in

• An SME accounting tool imports each operation — applied rate, both amounts, bank reference — and posts the FX gain or loss without manual entry.
• A treasury app polls the buy and sell rate and fires an alert when the pair crosses a target, then records the operation it triggered.
• A marketplace paying suppliers in dollars matches Tucambista settlement references against its payables ledger.
• A rate-comparison app shows Tucambista's live quote next to other Peruvian houses for the same amount.

Engineering details we plan around

Two things about this app shape the build, and we account for both:

• Rate-lock expiry. A quoted tipo de cambio is valid only for a brief window before the inbound transfer must be funded. We treat a captured quote as expiring, attach its validity, and re-fetch rather than ever serving a cached rate as current.
• Two-leg settlement states. An operation is not done until Tucambista's outbound bank transfer clears. We model the intermediate states (awaiting deposit, in validation, settled) and reconcile on the bank reference instead of assuming the inbound confirmation means the money moved.
• Person vs business accounts. Corporate operations carry an RUC, higher limits and at times several registered accounts. We scope those fields apart from individual DNI/CE profiles so a mixed customer base does not break the feed.
• Client-version drift. A mobile release can change request signing or headers. We keep a recheck step in maintenance so a version bump is caught before it interrupts the sync, and access for that check is arranged with you, not demanded up front.

Operating inside Peru's rules

Tucambista is registered with SUNAT and listed on the SBS casas-de-cambio registry administered through the UIF-Peru; that registry is mandatory and public, and we confirm the live entry at kickoff rather than asserting a number here. Personal data is governed by Peru's Ley N° 29733 and its regulations, so the integration is built data-minimized: only the operation and rate fields a use case needs, consent and access logged, NDA in place where the client requires it. There is no open-finance consent regime in force in Peru to rely on, which is why access is authorized directly by the account holder and recorded — that is the lawful basis the build runs on, and it is arranged with the client as part of the work.

Screens we mapped

What we checked, and when

In May 2026 we read Tucambista's Google Play and App Store listings for the operation flow and the figures it cites, the SBS casas-de-cambio registry for its supervisory status, and current Peru fintech and open-banking commentary to confirm no consent regime is yet in force. Stated company figures (volume exchanged, registered customers, settlement time) are quoted as the listings present them, not independently audited here.

Sources opened: Google Play listing, SBS casas-de-cambio registry, Chambers Peru Fintech 2025, IBA: open banking in Peru.

Reviewed in May 2026 by the OpenBanking Studio integration desk.

Peruvian exchange apps in the same picture

These run a similar online USD/PEN model; an integrator standardising across providers usually maps several to one schema.

• Rextie — one of the earliest SBS-registered online houses; holds per-user operation history and live rates.
• Kambista — popular consumer app with frequent-operation tracking and a rate feed.
• TKambio — real-time rate sourced from its providers, with a lean operation flow.
• Securex — oriented to companies and larger-volume treasury operations.
• Instakash — SBS-supervised, fast retail USD/PEN conversion with an account ledger.
• Cambix — straightforward web/app flow with operation records and quotes.
• Cambio Seguro — established digital house with per-account operation data.
• InkaMoney — soles/dollars exchange with registered-account settlement.
• Cambia FX — online USD/PEN exchange holding per-user conversion history.

Questions integrators ask first

Operations settle by bank transfer — can the feed capture the bank reference and settlement time, not just the quoted rate?

Yes. The operation detail and the constancia carry the origin and destination accounts, the bank reference and the settled timestamp, so the integration reconciles against your bank statement rather than stopping at the rate shown on screen.

Does a captured exchange rate stay valid, or does it expire?

It expires. Each buy or sell quote is good only for a short window before the inbound transfer must be funded, so the build treats every quote as time-boxed and re-requests it instead of serving a stale number.

Peru has no open banking in force yet — what authorized route does that leave?

The SBS open-finance framework is still at the roadmap stage rather than in force, so there is no consent endpoint to call. The route is authorized interface integration against a consenting Tucambista account, with operation-receipt export as a reconciliation fallback.

Can both business RUC accounts and individual accounts be covered?

Yes. Corporate operations carry an RUC, higher limits and sometimes several registered bank accounts; we scope those fields separately from individual DNI or CE profiles so both work in the same feed.

The source-code delivery starts at US$300 and is paid only after it lands and you are satisfied with it; if you would rather not run anything in-house, the same rate, operation and settlement endpoints are available as a hosted API you pay per call, with no upfront fee. Send the app name and what you want from its data through our contact page and we scope it on a one-to-two-week cycle.