Reading data out of The Evangeline Bank and Trust mobile app

Data domains in the app

Mapping each domain to where it actually originates inside com.therealbank.grip, what grain it carries, and a typical downstream use.

Integration routes for a small US community bank

The Evangeline Bank and Trust is a state-chartered commercial bank headquartered at 497 West Main Street, Ville Platte, LA 70586, FDIC certificate 12611, supervised by the FDIC as a Fed nonmember, operating roughly ten Louisiana branches as a subsidiary of Evangeline Bancshares, Inc. For an institution that shape, three routes make practical sense and we usually combine two.

Route A — consumer-permissioned aggregator (Plaid, Akoya, MX or Finicity)

The customer signs an authorization in your product; the aggregator handles the link to the bank; balances and transactions come back as normalized JSON. Akoya in particular has been moving these connections to tokenized API access rather than credential reuse, which is the direction the industry is heading. This route does not surface eStatements, RDC status, alerts or card-control state — only money-movement primitives.

Route B — authorized session client against the bank's own mobile surface (recommended spine)

Under the customer's signed authorization, we model the same calls the Android app itself makes after sign-in and drive them from a Python or Node.js client. This is the only route that reaches the surfaces an aggregator does not: alert rules, eStatement PDFs, mobile RDC submission status, debit-card lock state. We pair it with Route A for the money-movement spine where Route A is cleaner.

Route C — future §1033 path, if and when the rule survives reconsideration

If the CFPB's Personal Financial Data Rights rule emerges from reconsideration in a usable form and an institution of this size is in scope, a regulated data-access endpoint becomes another option. Today it is not the operative regime; we treat it as a forward-looking piece, not the basis of delivery (see Consumer authorization and §1033 posture).

Recommended shape: Route B as the spine because it reaches every surface the bank actually offers in the app, with Route A bolted on where a customer prefers an aggregator handshake or where you already have one wired.

What ships with the engagement

Order reflects the V=3 SDK-first focus — language clients first, paper artefacts second.

1. Python client SDK (3.11+) for sign-in, balance, transaction history, alerts, bill-pay history, mobile-deposit status polling, eStatement download. Idiomatic dataclasses, typed responses, async variants for the polling paths.
2. Node.js client SDK (18+) with the same surface, TypeScript types shipped, Promise-based, optional EventEmitter for the alert and deposit-status streams.
3. Runnable source for each endpoint we cover — not just a wrapper, but the request shaping, response parsing and the retry behaviour for the bank's MFA challenge.
4. Automated test harness — recorded fixtures plus a live-mode toggle that runs against a sandboxed test customer; CI-friendly, no GUI loop.
5. Sync and idempotency design — submission references for write paths (transfers, bill-pay, RDC), hashed transaction ids for read paths, replay-safe job runners.
6. OpenAPI 3.1 spec describing what we model, so your own services can codegen against it.
7. Auth-flow report covering the bank's MFA challenge, session lifetime, refresh behaviour and what triggers a re-prompt.
8. Compliance and data-retention memo: what the customer's signed authorization covers, what we keep in transit logs, redaction defaults.

Session and SDK shape

An indicative slice of the Python client against this bank's surfaces. The actual endpoint paths are confirmed during the build against a sponsored test customer, not invented up front.

from evangeline_client import EvangelineSession, SubmissionRef

sess = EvangelineSession.sign_in(
    username=USER,
    password=PASS,
    mfa_handler=sms_otp_callback,   # bank's challenge during refresh
)

# 1. balances and transactions for every linked account
for acct in sess.accounts():
    bal = sess.balance(acct.id)             # current + available, USD
    txns = sess.transactions(
        acct.id,
        since="2026-03-01",
        include_pending=True,
    )
    store.upsert_balance(acct.id, bal)
    for t in txns:
        store.upsert_transaction(t.hash_id, t)

# 2. eStatement PDF for the most recent cycle
for acct in sess.accounts():
    for stmt in sess.estatements(acct.id, limit=1):
        pdf_bytes = sess.estatement_pdf(stmt.id)
        archive.put(f"{acct.id}/{stmt.period}.pdf", pdf_bytes)

# 3. mobile RDC submission: status polling, not fire-and-forget
ref = SubmissionRef.new()
sess.rdc_submit(acct_id, front=front_jpg, back=back_jpg, ref=ref)
status = sess.rdc_status(ref, poll_until_terminal=True)
# status in {"accepted","on_hold","rejected"}
ledger.record_deposit(ref, status)

Node.js shape mirrors this — same method names, Promise return types, the same SubmissionRef contract for any write path.

Normalized transaction record

The shape downstream stores see, after the SDK has folded the bank's response into our common schema. Stable across both Route A (aggregator) and Route B (session client), so a switchover does not break consumers.

{
  "hash_id": "evb:9f3c…a1",        // stable; survives daily re-ordering
  "account_id": "evb:acct:00123",
  "posted_at": "2026-05-29T14:22:00-05:00",
  "effective_date": "2026-05-29",
  "amount_minor": -4280,            // USD cents, signed
  "currency": "USD",
  "pending": false,
  "channel": "debit_card",          // ach | debit_card | internal_transfer
                                    // | mobile_deposit | bill_pay
  "merchant_raw": "POS DEBIT  ROUSES MARKETS 47 VILLE PLATTE LA",
  "merchant_normalized": "Rouse's Markets",
  "counterparty": null,             // populated for ACH / bill-pay
  "source_route": "session"         // or "aggregator"
}

Consumer authorization and §1033 posture

For a Louisiana community bank of this size today, the dependable basis for moving customer data into your systems is the customer's own signed authorization, executed either directly into the session-client route or through a consumer-permissioned aggregator. That is the regime we build to.

The forward-looking piece is the CFPB's Section 1033 Personal Financial Data Rights rule. As of this writing it is in reconsideration: the agency issued an Advance Notice of Proposed Rulemaking on 22 August 2025, and on 29 October 2025 the U.S. District Court for the Eastern District of Kentucky issued a preliminary injunction barring the CFPB from enforcing the rule pending that reconsideration. The court found the rule likely exceeds the agency's statutory authority and is arbitrary on its data-security analysis. Whatever emerges may eventually apply to institutions like Evangeline; until it does, treating §1033 as settled would be premature, and we do not.

Things we handle during the build

• The bank's MFA challenge during session refresh. Refresh cadence is matched to what the mobile app itself does; the SDK exposes a mfa_handler hook so SMS OTPs or push approvals are routed wherever your operator can answer them.
• Pending-vs-posted reconciliation. A transaction often appears as pending one day and posted the next with a different timestamp; our hash id is stable across that transition so you do not get duplicates.
• Mobile RDC status polling. The deposit endpoint is not synchronous — the SDK keeps a job alive until the bank returns accepted, on-hold or rejected, and writes a single terminal row.
• Aggregator consent re-prompt cadence. When Route A is in the mix, we monitor the aggregator's consent-expiry signal and surface a re-prompt to your front-end before the link goes cold.
• eStatement deduping. Statement PDFs are content-hashed; a re-emitted statement (the bank occasionally re-publishes a month) does not produce a second archived copy.
• Schema versioning. The normalized record above is versioned; any breaking field change ships behind a feature flag with a deprecation window.

Engagement and how to start

Two pricing shapes cover the work: source-code delivery of the Python and Node.js clients from $300, paid only after delivery and once you are satisfied with what runs; or a pay-per-call hosted API where we operate the SDK and you bill by request, with no upfront fee. Either shape runs on a one- to two-week delivery cycle from a confirmed kickoff. To start, send us a brief description of which surfaces you need (balances and transactions, eStatement PDFs, mobile-deposit status, alerts, card controls) and the route you want to lead with, and we will come back with a concrete plan — /contact.html.

Sources

Bank facts (FDIC certificate, charter class, headquarters, history) and app feature list were taken from primary sources. Regulatory posture cites the CFPB's own reconsideration page and contemporaneous trade-press coverage.

• FDIC BankFind Suite — Institution Details (Cert #12611)
• The Evangeline Bank and Trust Company — About Us & Mission Statement
• The Evangeline Bank and Trust — Online & Mobile Banking features
• Google Play listing — com.therealbank.grip
• CFPB — Personal Financial Data Rights Reconsideration
• ABA Banking Journal — Kentucky federal court enjoins CFPB from enforcing the 1033 final rule

OpenFinance Lab · engineering notes, 2026-05-31

Comparable community-bank apps

• CBLA Mobile Banking (Community Bank of Louisiana) — holds Louisiana community-bank customer account balances, transfer history, bill pay payees, mobile deposit check images, and debit card control settings.
• Bank of Louisiana BOL — stores personal and business account balances, internal transfer records, bill payment data, and branch/ATM location lookups for a New Orleans community bank.
• Bonvenu Bank Mobile — holds North Louisiana customer deposit balances, transaction history, transfers, bill pay, and remote deposit capture images.
• CLB The Community Bank Digital Banking — stores Louisiana community bank account balances, internal/external transfers, bill pay activity, and e-statement records.
• AmeriServ Mobile Banking — holds Pennsylvania and Maryland community bank customer balances, transfer history, bill payments, and mobile check deposit images.
• CBNA Mobile Banking (Community Bank N.A.) — stores upstate New York / Northeast community bank account data including balances, transactions, payments, transfers, and deposited check images.
• Community Bank Personal Mobile (CommunityBank PA) — holds account history, inter-account transfers, scheduled bill payments, and Zelle person-to-person transfer records.
• Jack Henry Banno Mobile — white-label platform used by hundreds of community banks that holds account balances, transactions, transfers, bill pay, card controls, and secure messaging data.
• Fiserv Mobiliti / Architect Mobile — Fiserv-powered community bank mobile front-end that stores customer balances, transfer activity, bill pay payees, and remote deposit images.
• Quontic Bank Mobile — holds digital community bank customer balances, deposits, bill payments, transfer history, and credit-score monitoring data.

Questions we get

• How does the Python or Node.js client refresh data, and how often? The SDK polls the bank's authorized mobile session on a cadence we tune per use case: balances and the alerts feed every 15-30 minutes during business hours, transaction history every 2-4 hours with a 90-day rolling backfill, and eStatement PDFs once per cycle when a new month appears. Session tokens are rotated on the schedule the mobile app itself uses, so the bank's MFA challenge is exercised on the same beat as a real handset.
• What do we do if the mobile remote deposit upload fails server-side? Each RDC submission is bound to a client-generated submission_ref. The SDK keeps polling the deposit-status endpoint until the bank confirms accepted, on-hold, or rejected, then writes a single terminal record into your store. Partial uploads (e.g. only the front image went through) are retried against the same submission_ref so you do not get a duplicate deposit.
• Why route a Louisiana community bank through an aggregator like Plaid or Akoya? For an institution of this size, an aggregator pipe under the customer's signed consent is the lowest-friction path: the customer's online-banking credentials never sit in your service, Akoya in particular is moving its connections to tokenized API access, and the resulting balance and transaction records normalize cleanly across the peer apps we list. The bank's own surfaces (alerts, eStatement PDFs, card controls, RDC status) we cover with a separate session-based client, since aggregators do not expose them.
• Which fields end up in the normalized transaction record? Each transaction carries posted_at, effective_date, amount_minor, currency (always USD here), pending flag, merchant_raw, merchant_normalized, channel (ACH, debit-card, internal-transfer, mobile-deposit, bill-pay), counterparty routing where present, and a stable hash id so the same record is not re-emitted when the bank re-orders a daily batch.

Last checked 2026-05-31.