Pulling account history from The Evangeline Bank and Trust

Account data for customers of The Evangeline Bank and Trust Company sits behind go.therealbank.com. The same login, the same MFA, the same backend feeds the iOS and Android apps under com.therealbank.grip. For a third party with a member's written authorization to read those accounts — pull balances, normalize transactions, archive monthly statements — the technical question is not how to get in. It's which authorized path is steadiest right now. And that answer differs per bank.

This brief sets out what's reachable, the three paths we'd consider on a build like this, and what we'd hand to your team at the end of a one-to-two-week cycle.

What lives behind the login at this bank

Surfaces named the way the app itself names them, per the public Play Store description and the bank's own Online & Mobile Banking page:

Three authorized paths to the account

1. Member-consented aggregator coverage

Where The Evangeline Bank and Trust is reachable through an established aggregator — Plaid, MX, Finicity (Mastercard Open Banking), or Yodlee — we build against the aggregator's API with the member's consent flow. Coverage at small Louisiana community banks is uneven: Plaid's partnership with Fiserv added token-based pulls for many Fiserv-cored institutions in 2024 (per Plaid's announcement and PaymentsSource coverage), but other small banks still resolve through credential pass-through. We test the live connector against a consenting test account before deciding whether this path stays in the build.

2. Authorized interface integration of the portal

The same authenticated surface that backs the mobile apps — go.therealbank.com. We map the login, MFA channels, session and cookie chain, and the JSON or HTML endpoints behind the balance, transaction, statement, transfer and deposit views. Run under the member's explicit written authorization, with credentials held in a secret manager the member or your team controls. Durable as long as the portal's auth and endpoints are stable; we include a portal-change watcher in the maintenance plan so a UI revision doesn't quietly break the feed.

3. Native export bridge

Monthly statement PDFs are exposed through the portal, and most community-bank portals additionally allow transaction CSV or QFX export across a date window. For finance teams that need periodic reconciliation rather than a continuous feed, we wrap the export as a scheduled job, normalize the output, and emit it through an API the way real-time data would arrive.

For most builds at a bank this size, path 2 is the steady spine. It carries data regardless of whether an aggregator connector for this specific institution is reliable that quarter, and the export bridge slots in for older statement periods that the live endpoints don't cover. Where Plaid Link comes up clean against a consenting test account, we add path 1 in parallel for the OAuth-style consent UX many product teams prefer.

A first request, sketched against the portal

Illustrative shape only — actual endpoint paths, parameter names and MFA semantics are confirmed during the build by inspecting traffic from a consenting test account; we don't assert them here.

import httpx
from datetime import date

class EvangelineSession:
    BASE = "https://go.therealbank.com"

    def __init__(self, member_id, password, otp_provider):
        self.client = httpx.Client(follow_redirects=False, timeout=15)
        self._login(member_id, password, otp_provider)

    def _login(self, member_id, password, otp_provider):
        r = self.client.get(f"{self.BASE}/login")
        csrf = self._extract_csrf(r.text)
        r = self.client.post(
            f"{self.BASE}/auth/credentials",
            data={"memberId": member_id, "password": password, "_csrf": csrf},
        )
        if "mfa" in r.text.lower():
            code = otp_provider()                # member supplies via the consent UX
            self.client.post(
                f"{self.BASE}/auth/mfa",
                data={"code": code, "_csrf": csrf},
            )

    def accounts(self):
        r = self.client.get(f"{self.BASE}/api/accounts")
        r.raise_for_status()
        return [
            {
                "id":        a["accountId"],
                "type":      a["productType"],         # checking / savings / loan
                "available": a["availableBalance"],
                "current":   a["currentBalance"],
            }
            for a in r.json().get("accounts", [])
        ]

    def transactions(self, account_id, since: date, until: date):
        r = self.client.get(
            f"{self.BASE}/api/accounts/{account_id}/transactions",
            params={"from": since.isoformat(), "to": until.isoformat()},
        )
        r.raise_for_status()
        return r.json().get("items", [])

    def statement_pdf(self, account_id, period_yyyymm):
        r = self.client.get(
            f"{self.BASE}/api/accounts/{account_id}/statements/{period_yyyymm}",
            headers={"Accept": "application/pdf"},
        )
        r.raise_for_status()
        return r.content

Error handling, retry policy and session renewal live in the runbook we hand over — not in the snippet. Real responses get normalized into one schema across all three paths so the consuming app doesn't care which one served the data on a given call.

What lands at the end of the build

• An OpenAPI 3.1 spec covering accounts, transactions, transfers, statements and mobile-deposit events, with examples drawn from real consenting-account responses.
• A protocol report: the login flow, MFA channel options, session and cookie chain, refresh and expiry behavior, and the JSON shapes returned by each endpoint we use.
• Runnable Python client for the four core read endpoints, plus a Node port on request, with retry and rate-limit behavior wired in.
• An automated pytest suite that runs against a sandbox account or a consenting test member, including MFA replay and statement-parse cases.
• Interface documentation with worked examples, plus a maintenance runbook covering session expiry, MFA-channel changes, and recovery when the portal's front end shifts.
• A compliance pack: consent text, retention defaults, NDA template, audit-log schema, and a short data-minimization note.

Where US data rights sit for a 1907 community bank

The Evangeline Bank and Trust is well below the asset thresholds that CFPB §1033, as finalized in October 2024, would have phased in first — and the rule is in any case not in force right now: a federal court has enjoined enforcement and the CFPB issued an Advance Notice of Proposed Rulemaking in August 2025 reconsidering the framework, with the originally announced compliance dates stayed. We treat §1033 as the forward-looking piece, not as governing law. The dependable basis we operate under for this build is the bank member's own written authorization, scoped to the data they list and revocable.

GLBA and Regulation P still apply to any handling of consumer banking data on either side. We encrypt at rest, log access against the member who authorized it, hold credentials in a secret manager rather than in code, and minimize stored fields to what the build actually needs. An NDA covers the engagement; data-handling defaults are set out in the compliance pack.

Things we account for on this specific build

Four specifics that shape how we scope and run an integration at this bank:

• Joint-signer accounts are the norm. Many Acadiana retail relationships are joint, often across a family group. We capture which signer the consenting member is during authorization, and we do not silently merge another signer's individual accounts under the same consent — the calling app sees the distinction.
• Community Cash ATMs alongside the bank's own. When we surface ATM data we tag whether a location is a Community Cash partner or a direct Evangeline ATM, so downstream surcharge-free logic gets the right answer rather than treating all entries the same.
• Statement PDFs change template across years. Statements going back several years often arrive in two or three different layouts depending on when statement vendors changed. The parser detects template version and routes per-version, so a 2018 statement and a 2026 statement both normalize into one schema.
• MFA channel is per-member. The portal delivers MFA through whichever channel the member set up — SMS, voice, or email. We capture the choice during onboarding and let the consuming app re-prompt the member when re-auth is needed, rather than guessing or hard-coding a channel.

Access, sandbox credentials and the written authorization wording are arranged with the client as part of week-one onboarding — they are not a checklist for the reader to clear before getting in touch.

What we read for this brief

The factual claims here trace back to the bank's own public site, the public app store listings, and current US regulatory primary sources, cross-checked May 2026:

• therealbank.com — the bank's home and About pages (founding year, branch footprint, mobile-banking feature list).
• Google Play listing for com.therealbank.grip and the matching App Store listing (data domains, platform IDs).
• CFPB Personal Financial Data Rights Reconsideration and the August 2025 Federal Register ANPR (current §1033 status, stayed phase-in dates).
• Kansas City Fed briefing on data aggregators (how authorized aggregator access actually works in practice).

Compiled at the OpenBanking Studio integration desk · 2026-05-20.

Other Louisiana and community-bank apps in this category

Same category, same kind of integration problem — account balances and transactions behind a single authenticated portal at an independent state-chartered bank. Listed for ecosystem context, not as rankings:

• Community First Bank New Iberia — New Iberia, LA. Retail deposit accounts plus a separate business-banking app; account aggregation pattern is similar.
• Community Bank of Louisiana — Mansfield, LA. Free mobile banking with balances, transfers and bill pay behind the bank's own portal.
• Sabine State Bank — Many, LA. Full-service deposit and loan accounts; mobile app reads from the bank's own authenticated portal.
• First Federal Bank of Louisiana — Lake Charles, LA. Long-running community bank with a typical retail mobile-banking surface.
• First National Bank of Jeanerette — Jeanerette, LA. Account access across St. Mary, Iberia and Lafayette parishes through one portal.
• Home Bank — Lafayette, LA. Larger Acadiana community bank with retail and business portals as distinct surfaces.
• MC Bank — Morgan City, LA. Retail mobile banking covering balances, transfers and check deposit.
• Citizens Bank & Trust Company — Plaquemine, LA. Smaller Louisiana community bank with the same authenticated-portal pattern.
• Hancock Whitney — regional bank across the Gulf South; relevant when a client portfolio spans both community and regional institutions.

For builds that span several of these banks, we normalize all of them into one OpenAPI surface so the consuming app sees one schema.

Questions integrators ask before greenlighting this build

Does The Evangeline Bank and Trust show up reliably in Plaid or MX out of the box?

Coverage at small community banks is uneven and shifts between aggregator releases. During week one we run Plaid Link and the other major aggregators against a consenting test account; if a connector is live and reliable that quarter, we ride it. If not, the portal interface integration carries the build and the aggregator route is added later when it firms up.

We have business customers with cash-management accounts at this bank — does that change anything?

Yes. The cash-management portal at most Acadiana community banks runs as a separate authenticated surface from retail mobile banking, with its own MFA and entitlement model. We scope it explicitly: if the build needs to read business sweep accounts as well as retail, we map both portals.

How do you handle MFA when the integration runs unattended?

For attended pulls we relay the OTP through the calling app's UX. For unattended runs we hold a long-lived session per the portal's own rules and let the member re-authorize when it expires. We do not bypass MFA and do not store one-time codes.

How current is the data we receive — real-time, or batched?

As current as the portal itself. Balances and posted transactions reflect what a member would see by logging into go.therealbank.com at that moment. Pending items and same-day ACH appear when the bank surfaces them; statements arrive on the bank's monthly cycle.

Source-code delivery starts at $300, billed only after the build lands and you've signed it off; the same integration is available as a pay-per-call hosted API with no upfront fee. Either way the cycle runs one to two weeks. To start the conversation about a build against The Evangeline Bank and Trust, contact the integration desk.

Mapping reviewed 2026-05-20.