St. Landry Bank Mobile sits on FIS Digital One — here is the route to its account records

The interesting records are not on the device. St. Landry Bank Mobile is a thin client over an FIS Digital One Flex back end, and the balances, posted transactions, scheduled payees and transfer history all live server-side, fetched per session after a signed-in token exchange. That is the surface worth integrating. For a partner that wants to read a St. Landry account holder's data into another system — a bookkeeping tool, a lender's underwriting flow, a treasury dashboard — the practical path is to reproduce that authenticated session under the account holder's authorization and read the same endpoints the app reads.

We do that work and hand back source you can run. The route below is the one we would take here; the rest of this page is what it touches and what you receive.

Account data behind the FIS Digital One login

The app names its own surfaces. Mapped to what an integrator would actually consume:

Routes to the balances, transfers and bill-pay records

Consent-based protocol integration of the Digital One session

Reproduce the app's authenticated session against the FIS back end, with the account holder's consent, and read the same JSON the app renders. This reaches every domain in the table at the granularity the app itself shows. Effort sits in the auth chain — the login token, the MFA step-up, the session refresh — and in mapping each screen to its endpoint. Durability is good once the token flow is captured; the maintenance risk is a platform-side change to that flow, which we plan for. This is the route we would run for St. Landry.

User-consented credential access

A narrower variant where the account holder grants credentials into a controlled, logged flow and we pull a defined set — typically balances and a transaction window — on a schedule. Lighter to stand up, less surface area, well suited to a single recurring export rather than a full mirror.

Permissioned aggregation under US consumer authorization

Where a downstream aggregator or AIS-style consent layer is already in play, we fit the integration to it so the consent record and revocation are handled in one place. Reach depends on what that layer exposes; it can sit in front of either route above.

For this app the first route is the one that actually returns the full record set, so it is what we build the spine of the project around; the credential-access route is the lighter option when a client only needs a recurring balance-and-transaction feed.

A statement pull, sketched

The shape of the session, drawn from how FIS Digital One Flex behaves. Paths are illustrative and get confirmed per tenant during the build:

# 1. Authenticate — Digital One Flex returns a token, then asks for step-up
POST /dbweb/api/v0/auth/login
  { "userId": "...", "password": "...", "deviceId": "..." }
  -> 200 { "accessToken": "...", "refreshToken": "...", "mfaRequired": true }

# 2. Biometric / OTP step-up exchanges for a session-scoped bearer
POST /dbweb/api/v0/auth/mfa
  { "factor": "biometric", "assertion": "..." }
  -> 200 { "accessToken": "<session-scoped>", "expiresIn": 600 }

# 3. Read transactions for a window, searchable like the app's UI
GET /dbweb/api/v0/accounts/{acctId}/transactions
     ?from=2026-01-01&to=2026-03-31&searchBy=amount
  Authorization: Bearer <session-scoped>
  -> 200 {
       "runningBalance": "...",
       "items": [
         { "postedDate": "...", "amount": "...",
           "checkNumber": "...", "type": "debit", "description": "..." }
       ] }

# on 401, replay refreshToken before re-prompting the account holder
      

The point of the report we deliver is to turn that sketch into the confirmed chain — real field names, real error codes, the exact refresh behaviour — so your engineers are not guessing.

What lands in your repo

• An OpenAPI/Swagger spec covering the accounts, transactions, bill-pay and transfer endpoints as they actually respond for St. Landry's tenant.
• A protocol and auth-flow report: the login token exchange, the biometric/OTP step-up, the session-scoped bearer and the refresh cycle, written so a new engineer can follow it.
• Runnable source for the key calls in Python and Node.js — authenticate, list accounts, page transactions by date or amount or check number, read transfer and bill-pay state.
• Automated tests against recorded responses, so a platform-side change surfaces as a failing test rather than a silent gap.
• Interface documentation and data-retention guidance: what each field means, what is stored, what is dropped.

Consent and the US data-rights picture for a Louisiana community bank

St. Landry Bank is a US community bank, so the integration rides on the account holder's own authorization to reach their data — a consent we record, scope to named domains, and let the holder revoke. That consent is the dependable basis, today and regardless of how federal rulemaking lands.

The CFPB's Section 1033 Personal Financial Data Rights rule is where US open banking may eventually be codified, but it is not in force: a federal court in the Eastern District of Kentucky enjoined enforcement in October 2025, and the Bureau has put the rule back into reconsideration. We treat §1033 as the forward-looking piece a St. Landry integration should be ready for, not as present law it depends on. Our posture is the same either way: authorized access only, consent and access logged, data minimized to what the use case needs, NDA where the client wants one.

Where the build needs care

Two things on this app specifically shape how we scope it.

The MFA step-up is the part that breaks naive integrations. FIS added biometric and OTP login to Digital One, so a session is a two-step token exchange, not a single password post. We design the sync around capturing and replaying the refresh and session-scoped tokens, so it re-authenticates on its own and only falls back to prompting the account holder when the refresh genuinely expires.

The money-movement surfaces are not uniform. Internal transfers, external transfers, Zelle and loan payments share the session but carry different status models and timing. We map each as its own endpoint with its own state fields rather than flattening them into one transfer object, because a downstream ledger that treats a pending external transfer like a settled internal one will misreport. Access to a consenting account or a sponsor environment is arranged with you during onboarding; the build runs against that.

Three builds this supports

• A bookkeeping connector that pulls posted transactions nightly, keyed on posted date and check number, and reconciles against an accounting ledger.
• A lender reading 90 days of balances and transaction history, once, under a borrower's consent, to support an underwriting decision.
• A treasury view that mirrors balances and pending transfers across a business's St. Landry accounts into an internal dashboard.

What the app screens show

The published screenshots, as a quick read on the surfaces named above. Tap to enlarge.

Sources and method

Checked in May 2026 against the app's store listing and the bank's own pages, FIS's description of the Digital One Flex mobile platform the app runs on, and the current status of US data-rights rulemaking. The route and the field sketch reflect how that platform behaves; tenant-specific paths are confirmed during the build.

• St. Landry Bank Mobile on Google Play
• St. Landry Bank — Mobile Banking Apps
• FIS — Digital One mobile banking application
• CFPB — Personal Financial Data Rights Reconsideration
• ABA Banking Journal — court halts §1033 enforcement

OpenBanking Studio · integration desk mapping, May 2026.

Comparable Louisiana and community-bank apps

Same category, useful when one consent layer needs to span several community-bank clients. Named for context, not ranked:

• Gulf Coast Bank & Trust mobile — New Orleans and Baton Rouge community bank; holds balances, transfers and bill pay behind a signed-in session.
• CBLA Mobile (Community Bank of Louisiana) — balances, transfers, bill pay and mobile deposit for its account holders.
• Investar Bank mobile — full-service Louisiana community bank with accounts, bill pay and cash-management records.
• Home Bank mobile — Louisiana bank holding the same retail account and payment surfaces.
• JD Bank mobile — Southwest Louisiana community bank with balances, transfers and deposit capture.
• Bank of Louisiana mobile — personal mobile banking with account and transaction data.
• MidSouth-area community bank apps — comparable retail deposit and payment records behind login.
• 1st Source Bank mobile — another FIS-platform community bank app with a similar session model.

Questions integrators ask about St. Landry Bank Mobile

Which records can be reached through an FIS Digital One session for St. Landry Bank Mobile?

Everything the app shows a signed-in customer: account balances and running balances, transaction history searchable by date, amount or check number, scheduled and paid bills, internal and external transfers, and remote-deposit records. We map each one to a documented request and response pair.

Does the stalled CFPB open-banking rule block a St. Landry Bank Mobile integration?

No. The Section 1033 rule is enjoined and back in reconsideration, so it is not the basis we build on. The dependable footing is the account holder's own authorization to reach their data; the build runs against a consenting account or a sponsor environment arranged during onboarding.

How do you handle the biometric step-up and the Zelle and external-transfer surfaces?

The login is a token exchange with an MFA step; we capture the refresh and session-scoped token chain so the sync re-authenticates without manual logins. Zelle and external transfers sit behind the same session and are mapped as separate endpoints, each with its own status fields.

Both ways of buying are simple. Source-code delivery starts at $300 — you receive the runnable API source, the spec, the tests and the docs, and you pay after delivery once it works for you; or run against our hosted endpoints and pay per call with nothing upfront. Either fits a 1–2 week cycle. Tell us the requirement and we will take it from there — start the conversation here.