Reaching 1st Source Bank account data through consented open-finance access

1st Source Bank has held its own charter since 1863 from South Bend, Indiana, per its Wikipedia entry, and the mobile app is where deposit, card, loan and Zelle activity for those customers actually lives. The bank runs roughly 78 banking centers across Indiana, Michigan and Florida (per bankbranchlocator.com) and trades as 1st Source Corporation, NASDAQ: SRCE (per Yahoo Finance). For an integrator the useful fact is narrower: a 1st Source customer's accounts are already reachable today through consumer-permissioned aggregation — the institution is listed as supported via Plaid on Open Banking Tracker — and the durable path is FDX-aligned consent rather than a brittle screen capture.

The bottom line: the data worth integrating is conventional retail-bank data, and most of it moves cleanly over a consented aggregation connection. The route we would actually run is a consumer-permissioned link as the backbone, with a thin authorized-session layer to pick up the things an aggregation feed does not carry — Zelle status, Card Control state, push-alert events. Native document export covers the rest.

What customer records 1st Source holds

These map to surfaces named the way the app itself names them in its store listing and online-banking flow.

Routes that apply here

1 · Consumer-permissioned open-finance access

1st Source is reachable through the US aggregation network — the institution appears as a supported provider via Plaid on Open Banking Tracker, and the same data is addressable through Akoya, MX or Finicity connections. Where the bank exposes FDX endpoints the connection is OAuth-based and token-scoped; where it does not yet, the aggregator tunnels the consented session. This carries deposit balances and transaction history dependably. Effort is low to medium, durability is high. We set up the aggregator application, the consent screen and the data-provider mapping with you during onboarding.

2 · Authorized protocol work on the app session

The app talks to an institution-scoped mobile backend. Under your customer's authorization we capture and document that traffic to read what the aggregation feed leaves out: Zelle status, Card Control on/off and limits, alert events, mobile-deposit state. Effort is medium; durability is medium because a banking-platform front-end change needs a re-validation pass. The build runs against a consenting 1st Source account.

3 · Native export as a document fallback

E-statement PDFs and in-app paper check images cover historical artifacts. Low effort, high durability, coarse latency — right for evidence, wrong for live signals.

What we would recommend, plainly: run route 1 as the backbone because it is the most durable and the cleanest to consent; layer route 2 only over the app-native domains it is needed for, so the surface we have to maintain stays small; keep route 3 for documents. That mix gives the widest data coverage for the least long-term maintenance.

A worked example: balances and transactions, then the gaps

# Illustrative. Endpoint shapes and field names are
# confirmed during the build against a consenting account.

POST /oauth2/token
  grant_type=authorization_code
  code=<consent_code_from_aggregator_flow>
  # The consent flow returns a token bound to the 1st Source
  # data provider only — institution scope is fixed here.

GET /fdx/v6/accounts
  Authorization: Bearer <access_token>
  Accept: application/json
-> 200
   { "accounts": [
       { "accountId": "src-7001-xxxx",
         "accountType": "CHECKING",
         "balanceAsOf": "2026-05-15T08:02:11Z",
         "currentBalance": 4185.22,
         "availableBalance": 4060.22,
         "routingTransitNumber": "0710xxxxx" } ] }

GET /fdx/v6/accounts/{accountId}/transactions
      ?startTime=2026-02-01&endTime=2026-05-15
-> 200  # paginated; cursor returned in nextCursor
   { "transactions": [
       { "transactionId": "...", "postedTimestamp": "...",
         "amount": -62.40, "description": "ZELLE TO ...",
         "status": "POSTED", "checkNumber": null } ],
     "nextCursor": "eyJvZmZ..." }

# App-native gap fill (authorized session): Zelle status,
# Card Control state + limits, push-alert events. These are
# not in the FDX feed; we map them into the same schema.
# Backoff on HTTP 429; refresh the token before expiry so
# the consent does not lapse mid-sync.
      

What lands in your hands

Each deliverable is tied to a real 1st Source surface, not a generic template.

• An OpenAPI specification covering the accounts, transactions and statement endpoints as consented, plus the normalized objects for the app-native domains.
• A protocol and auth-flow report: the OAuth/token chain on the aggregation side and the session chain on the app side, written for the institution-scoped backend specifically.
• Runnable source for the key calls in Python and Node.js — token exchange, paged transaction pull, Zelle and Card Control mapping, statement retrieval.
• Automated tests, including a conformance suite that replays the captured calls so a platform change is caught early.
• Interface documentation and a data-retention note that matches the consent scope you grant.

Integrations people ask for with this bank

• A bookkeeping product that pulls 1st Source checking and savings transactions nightly, with check images attached to the matching ledger lines.
• A lender that needs 60–90 days of transaction history plus current balance for a small-business cash-flow decision, sourced through consent rather than uploaded PDFs.
• A treasury dashboard that mirrors Card Control state and reacts to push-alert events in near real time instead of polling balances.
• An accountant portal that ingests monthly e-statements and reconciles them against the live transaction feed.

Consent and the US data-rights picture

The framework here is the CFPB's Personal Financial Data Rights rule under Dodd-Frank Section 1033. It was finalized in October 2024, then enjoined and reopened for reconsideration — the CFPB issued an advance notice of proposed rulemaking in August 2025 and the comment window has closed (per the CFPB's rules-under-development page and the Federal Register). Because the rule's specific obligations are unsettled, this brief does not state compliance dates or covered-entity thresholds as fixed; they are in flux and are not asserted here. The Financial Data Exchange has been recognized by the CFPB as a standard-setting body, so the FDX API is the practical technical shape the market is converging on regardless of how the rulemaking finishes.

What that means for the work: we do not rely on the rule being in any particular state. The basis is consumer-permissioned access under your customer's explicit authorization, scoped to the data domains you actually need, time-boxed, and revocable by the customer at any point. We keep consent records and access logs, minimize stored fields to what the use case requires, and work under an NDA where the engagement calls for one. That is how the studio operates, not a gate the reader has to clear.

Details we plan around

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

• Shared-tenant package. The Android namespace, per the Play Store listing, is the multi-institution form com.ifs.banking.fiid7001, with the trailing identifier scoping the institution. We pin the integration to 1st Source's institution id and session domain so authentication and routing stay institution-correct; the protocol mapping is reusable but never crosses into another bank's tenant.
• Aggregation-versus-app split. The consented feed reliably carries deposit balances and transactions, while Zelle status, Card Control state and alert events are app-native. We map those from the authorized session into the same normalized schema rather than leaving holes, so a consumer of the API sees one consistent object.
• Consent lifetime. We design the sync around the token's lifetime and refresh cadence so the connection does not silently expire; re-consent is scheduled, not discovered when a job fails.
• Access setup. Access is arranged with you during onboarding — the build runs against a consenting 1st Source account or a sponsor sandbox, whichever stands up faster.

Keeping the feed honest after launch

A scheduled conformance check re-runs the captured calls after each app release, so a banking-platform UI or endpoint change shows up in CI rather than in a customer's failed sync. Balance and transaction freshness tracks the aggregation provider's refresh; alert-driven events arrive faster and are the right signal when latency matters. We document the expected staleness per domain so downstream logic is not built on a wrong assumption.

How an engagement runs

There are two ways to work with us, and the choice is yours. First, source-code delivery: we build and hand over the runnable integration, specification, tests and documentation for a fee starting at $300, and you pay only after delivery once you have checked it does what you need. Second, a pay-per-call hosted API: we run the integration, you call our endpoints and pay per call, with no upfront fee. A typical delivery cycle is one to two weeks. The app name and what you want from its data is the starting point; access and compliance paperwork are arranged with you as part of the engagement.

App screens

Store screenshots, useful for confirming which surfaces the listed data domains come from.

Peer banking apps in the same integration scope

Same-category apps an integrator often wants under one unified data layer. Listed neutrally — none is ranked against the others.

• Lake City Bank Digital — northern and central Indiana customer accounts, transactions and transfers behind a login.
• Centier Bank Mobile — Indiana retail deposits with mobile deposit and P2P payment records.
• Horizon Bank Mobile Banking — Indiana and Michigan deposit and card data with online-banking history.
• Old National Bank — Midwest retail and small-business accounts, payments and statements.
• German American Bank — southern Indiana deposit, loan and bill-payment records.
• Everwise Credit Union — former Teachers Credit Union, member share and loan accounts with transaction history.
• Notre Dame Federal Credit Union — member deposit and loan data behind authenticated access.
• Huntington Mobile — multi-state retail accounts, cards and transfers at larger scale.
• Fifth Third Mobile Banking — regional bank deposits, cards and payments across several states.

The point of listing them: a customer-facing product rarely connects only one bank, and the same consented-access pattern that works for 1st Source extends to these. Tell us which set you need and the unified schema is designed once.

Sources checked

This mapping was put together in May 2026 from the app's store listing and online-banking flow, the CFPB rulemaking record, the FDX standard, and a provider-coverage check. Primary references opened:

• CFPB — Personal Financial Data Rights Reconsideration
• Federal Register — §1033 Reconsideration notice (Aug 2025)
• Open Banking Tracker — 1st Source Bank via Plaid
• 1st Source — Online & Mobile features

Mapped by the OpenBanking Studio integration desk, May 2026.

Questions integrators ask about 1st Source

Does the open-finance connection cover Zelle and Bill Pay, or just balances and transactions?

Balances and posted transactions come through the consumer-permissioned aggregation feed reliably. Zelle send and receive status, scheduled transfers and Bill Pay payees are app-native surfaces, so we read those from the authorized app session and fold them into the same normalized schema instead of leaving gaps.

The CFPB Section 1033 rule is back in reconsideration — does that put the integration at risk?

No. The route rests on consumer-permissioned access under your customer's authorization through FDX-aligned rails, which holds regardless of how the rulemaking lands. We track the docket and adjust the consent and retention design if the final shape changes.

1st Source's app appears to run on a shared community-bank platform — does that complicate the work?

The Android package namespace, per the Play listing, is multi-institution with a trailing identifier scoping 1st Source specifically. We pin the integration to that institution's session and routing so authentication stays correct, and the protocol mapping is reusable without ever crossing into another bank's tenant.

Can you also retrieve historical statements and paper check images, not only live data?

Yes. E-statement PDFs and the in-app check images are reachable as a document fallback, at monthly statement granularity plus per-item check images, which is the right source for proof-of-income and reconciliation evidence.