A working route into Bi en Línea, Banco Industrial's mobile bank

Banco Industrial's retail front-end handles quetzal and dollar deposit accounts, domestic and cross-border transfers, FX between the two currencies, remittance reception for both customers and walk-ins, the QR rail it shares with Cuik and ZIGI, cardless ATM withdrawal via QR, and bill settlement across more than two thousand merchants — per the app's Play Store listing. Every one of those flows sits behind the same authenticated session at bienlinea.bi.com.gt and inside the same gt.com.bi.bienlinea mobile shell. That session is what the integration actually targets.

The short version. Guatemala doesn't yet have a regulated AIS rail in force, so the dependable basis for reading a Bi en Línea customer's data is the customer's own consent — captured properly, logged, and revocable. We treat the existing portal and mobile shell as the integration substrate and hand back a clean, normalized API on top.

Data the app holds for each customer

The list below names the surfaces we typically expose. Field names lean on what the portal itself calls them in Spanish; the integrator-facing schema we ship is in English and normalized.

The route we would take into this portal

Authorized interface integration against the existing session

This is the route we run. The customer authenticates as they normally would — username and password, plus the second factor (SMS-OTP or push to the registered handset) — and the consenting session becomes the substrate. Coverage matches what the customer can see in the portal, which is the broadest reach available. Durability is solid week-to-week. When Banco Industrial refreshes its front end, parsers tied to the HTML can drift; we catch that with a short selectors check that runs before any production fetch, and we ship the patch the same day rather than letting a downstream feed go quiet.

Native PDF export as a fallback

The portal can render a statement PDF on demand. Useful for batch back-fills and for archive accounts that don't need a live session. We treat it as a complement to the primary route, not a substitute — the PDF carries the statement but not the richer descriptor and rail metadata.

Consumer-consented headless integration

Same authorization, no human in the loop after the first consent capture. The build keeps a refresh-aware loop and stops cleanly when the customer revokes. This is what most PFM and SME-accounting projects end up using day to day.

We typically run the build on the first route and fall back to the PDF path for accounts that can't sit on a live session — for example dormant USD accounts where the customer would rather not have their session warmed every day.

Guatemala's consent picture, plainly

Two facts shape this. First, Guatemala doesn't yet have a regulated open-finance regime in force — the country sits on the open-finance trackers as still working on a framework, alongside Peru and Mexico. Second, Guatemala has no general data-protection statute for the private sector; the habeas data right under Decree 57-2008 (Ley de Acceso a la Información Pública) is mostly anchored to public registries, per the DLA Piper jurisdiction guide.

Practically that means the dependable basis for this work is the account holder's own consent. We capture it in writing, log the timestamp and scope, scope the access to the domains the client actually needs, never persist credentials past the runtime, and honour revocation on the same business day. The Superintendencia de Bancos de Guatemala (SIB) regulates Banco Industrial as a prudential matter; nothing the integration does should put either side outside their consumer-protection posture, and we accept an NDA before access.

Things this app makes you account for

• The shared QR rail. Banco Industrial's QR is interoperable with Cuik and ZIGI. The portal mixes events from all three rails in one feed; the descriptor codes differ. We tag every QR event with its origin so reconciliation downstream can tell a Cuik handle from a ZIGI handle from a card-less ATM redemption.
• GTQ and USD on the same statement. Many Banco Industrial customers run both currency lines under one user. The portal lists them together. We carry currency on every record and stamp historical FX against the entry date, so a Q&A tool that renders dollar movements doesn't re-convert them at today's rate.
• Two-factor handoff. The second factor lands on the customer's registered handset, not in any session we hold. We design the consent capture so the OTP flows through the customer's own input on first authorization, and the refresh loop after that is silent for as long as the cookie window allows.
• Locale drift. The portal supports both Spanish and English (URL path /InicioSesion/Inicio/Autenticar/en-US). Movement descriptors can shift slightly between locales. We pin our parsers to en-US for stability and re-test when Banco Industrial updates the front end.
• DPI-based onboarding. The app onboards new customers using only their DPI and a selfie, per the Play description. That flow lives outside the integration's read path — but it does mean the population we read against includes accounts that were never visited in a branch, so we don't assume a Mi Bi card has been issued before reading the deposit history.

What lands in the client's repo

• An OpenAPI 3.1 specification covering the eight to ten Bi en Línea surfaces the project actually needs — accounts, movements, transfers, remittance receipts, QR events, card actions, bill payments, in-app insurance.
• A short auth-flow report: the login dance at bienlinea.bi.com.gt, the second-factor handoff, cookie / session lifetime as observed during the build, and the silent-refresh window.
• Runnable Python source (httpx + a thin parser for the HTML-rendered sections) for every endpoint in the spec, plus a Node port for clients who run a NestJS or Fastify gateway.
• Pytest fixtures that exercise the surfaces against a consenting account, including the revocation path.
• Interface documentation: a single HTML reference with descriptor maps, the GTQ / USD normalization rules, and the rail-tag taxonomy for QR events.
• A short consent-and-retention note the client can hand its compliance team, covering Guatemala's habeas data picture and the data-minimization defaults the build ships with.

A short look at the protocol

An illustrative read path — exact field names get confirmed during the build against a consenting account.

# Illustrative — exact keys and the second-factor exchange
# get pinned during the build, against a consenting account.
import httpx

BASE = "https://www.bienlinea.bi.com.gt"

async def session_for(creds):
    s = httpx.AsyncClient(base_url=BASE, follow_redirects=True)

    # 1. Bootstrap the en-US login page; capture the rolling form token.
    landing = await s.get("/InicioSesion/Inicio/Autenticar/en-US")
    token = extract_request_verification_token(landing.text)

    # 2. Primary auth — credentials supplied under explicit consent.
    await s.post(
        "/InicioSesion/Autenticar",
        data={
            "usuario": creds.username,
            "clave":   creds.password,
            "__RequestVerificationToken": token,
        },
        headers={"X-Requested-With": "XMLHttpRequest"},
    )

    # 3. Second factor: OTP relayed to the customer's registered handset.
    await s.post("/InicioSesion/SegundoFactor",
                 data={"otp": await creds.otp(), "__RequestVerificationToken": token})
    return s

async def movements(s, account_id, days=90):
    r = await s.get("/Cuentas/Movimientos",
                    params={"cuenta": account_id, "rango": days})
    for m in r.json()["items"]:
        yield {
            "transaction_id": m["correlativo"],
            "posted_at":      m["fechaContable"],
            "amount":         m["monto"],
            "currency":       m["moneda"],          # "GTQ" or "USD"
            "counterparty":   m.get("descripcion"),
            "rail":           classify_rail(m),     # BI-QR · Cuik · ZIGI · ATM · transfer
        }

Use cases this build typically serves

• A Guatemalan PFM that wants statements categorized, with the GTQ and USD ledgers reconciled into a single view.
• A remittance product showing recipients their incoming Banco Industrial, Cuik and ZIGI credits in one feed, with the corridor metadata kept intact.
• An SME-accounting SaaS that pulls month-end statements on a schedule for clients who hold both quetzal and dollar accounts at Banco Industrial.
• An employer-of-record platform that needs payroll-confirmation lookups against employee account credits before releasing benefits the following week.

Neighbouring apps in the Guatemalan stack

These are the apps an integrator running a Guatemala-wide product usually has to think about alongside Bi en Línea. Plain text; we don't rank them.

• Bi Banking — Banco Industrial's companion app for corporates and SMEs, with tax payments, check authorizations and bulk operations.
• Bi Pay — Banco Industrial's merchant-acceptance app for the same QR rail Bi en Línea consumes.
• ZIGI — joint Banco Industrial / Intermex remittance wallet launched in late 2025 on the Thought Machine core, sharing the QR rail with Bi en Línea.
• Cuik — the Banco Industrial digital-wallet brand, interoperable with the same QR network.
• Banca Móvil Banrural — Banco de Desarrollo Rural's retail app, the second large Guatemalan deposit holder.
• GTCApp — Banco G&T Continental's retail app, with transfers, bill and tax payments.
• Banco Promerica Guatemala — Promerica's app, with own-account and third-party transfers and the usual multipayment menu.
• BAC Credomatic — BAC's Guatemalan retail app, frequently cited as among the most polished local banking apps.
• BAM Móvil — Banco Agromercantil's retail app.
• Banpaís — the Honduran sibling under the Banco Industrial group, often relevant for cross-border integrations on the same group rails.

How this brief was put together

The app description and the route map were checked against the Play Store and App Store listings for gt.com.bi.bienlinea / id 510761055; the open-finance status of Guatemala was checked against the Open Banking Tracker and the Ozone Open Finance Atlas; the data-protection posture was checked against DLA Piper's Guatemala chapter and the Consortium Legal Central America Q&A. Where Banco Industrial publishes specific terms (login flow at bienlinea.bi.com.gt, Cuik / ZIGI interoperability) those were checked directly. Re-checked on 2026-05-19.

• Play Store: Bi en Línea (gt.com.bi.bienlinea)
• Open Banking Tracker — Guatemala country page
• Ozone Open Finance Atlas — Guatemala
• DLA Piper Data Protection Laws — Guatemala

Mapped by the OpenBanking Studio integration desk · checked 2026-05-19.

Questions integrators usually raise

Can a Bi en Línea integration cover quetzal and dollar accounts in the same session?

Yes. The portal lists GTQ and USD accounts together for the same customer, and the session that authenticates one authenticates both. We carry the currency on every record we hand back, and we record FX rates against the entry date so dollar movements don't get re-converted at today's rate when a client app renders them.

Do the cardless-ATM QR, the Cuik handle and the ZIGI handle all flow through the same authorization?

They flow through the same authenticated session, but the descriptor codes differ by rail. Our parser tags each instant-payment event with its origin (Banco Industrial QR, Cuik, ZIGI, cardless-ATM redemption) so the downstream system knows which network paid and can reconcile against the right ledger.

Does Guatemala not having a formal open-banking regime change how you scope the work?

It changes the legal basis, not the engineering. With no domestic AIS regime in force, the authorization is the account holder's own credential grant, captured under NDA and consent record. We design the build so it stops cleanly when the customer revokes, and we never persist credentials beyond the runtime.

If a Guatemalan open-finance regime comes online later, does the build we ship now have to be rewritten?

No. Our deliverables are written around a normalized account / movement / transfer schema. Moving the transport from a consenting portal session to a regulated AIS endpoint is a swap inside one module, not a rewrite of what sits on top. The OpenAPI spec we hand you stays the contract either way.

Pricing is plain. Source-code delivery starts at $300, with payment due only after delivery once the client is satisfied with the work; the alternative is the pay-per-call hosted API, where you call our endpoints and pay only for the calls you make, with nothing up front. Build cycle is one to two weeks either way. Send the app name (Bi en Línea) and a short note on what you need from the data to /contact.html — access, consent capture and the NDA are arranged with you during onboarding, not asked of you up front.