Pulling Dirigo FCU Mobile Banking data into your own systems

Quick read on the member data

Balances, dated transaction history, internal transfers, mobile-deposit records and loan payoff figures all sit behind one member login here — and the Dirigo Investing tab adds brokerage positions on top of that. For a credit union this size, the integration worth buying is rarely a single snapshot. It is a dependable feed: one deep backfill of the member's history, then a steady trickle of new postings.

That is the shape we build to. The recommended route is reading the app's own member-authenticated traffic under the member's consent, normalizing what comes back, and handing you code you can run on your own schedule. The credit union does not publish the name of its underlying digital-banking platform, and the build does not need it — we work from the live member session, not a vendor identity.

What the app actually stores per member

These are the surfaces the app exposes to a logged-in member, mapped to what an integrator would do with each. Granularity reflects what a member sees on screen, confirmed against the credit union's own description of the app.

Reading a member's transaction history

Here is the core of a backfill, written against the surface that matters most for this app: dated postings on a share or loan account. Endpoint shapes are illustrative and get confirmed against the live app during the build — they are not lifted from any vendor document. Authentication rides the app's own session-token chain.

# 1) Device-bound login -> short-lived bearer token
POST  /auth/session
      { "memberId": "<member>", "deviceId": "<registered-device>" }
   -> { "accessToken": "...", "expiresIn": 900 }

# 2) Bulk backfill: walk one account's history by cursor, oldest first
GET   /accounts/{shareId}/transactions?since=2021-01-01&cursor=<next>
      Authorization: Bearer <accessToken>
   -> {
        "items": [
          { "id":"txn_8f2a", "postedAt":"2026-06-11",
            "amount":-42.18, "currency":"USD",
            "description":"POS PURCHASE — LEWISTON ME",
            "runningBalance":1190.44, "type":"debit" }
        ],
        "nextCursor": "eyJwYWdlIjo3fQ"
      }

# 3) Resume safely. If a backfill stops mid-run, the next start
#    picks up at the last stored cursor instead of re-reading the lot.

Incremental syncs reuse the same call with a recent since date, so a daily job only fetches what posted since the last cursor. Mobile deposits get the same treatment, but we read their status field too — a deposit can be submitted, on hold, then cleared, and a feed that ignores that just shows a stale amount.

A normalized shape for the records

Raw responses differ account to account. We flatten them into one stable shape so your code does not care whether a row came from a checking share, a loan, or the investing tab.

{
  "account": {
    "id": "acct_share_01",
    "kind": "share|loan|brokerage",
    "label": "Primary Savings",
    "balanceCurrent": 1232.62,
    "balanceAvailable": 1190.44,
    "currency": "USD"
  },
  "transaction": {
    "id": "txn_8f2a",
    "accountId": "acct_share_01",
    "postedAt": "2026-06-11",
    "amount": -42.18,
    "direction": "debit",
    "description": "POS PURCHASE — LEWISTON ME",
    "status": "posted",
    "source": "core-banking"
  }
}

What lands in your repository

The headline deliverable is code that runs, not paperwork. Concretely, for Dirigo FCU you get:

• A runnable ingestion client in Python and Node.js — login, balances, and the cursor-paged transaction read above.
• A backfill-and-sync runner: one command for the deep history pull, another for the incremental delta job, both resumable.
• An automated test suite running against recorded response fixtures, so the parsing logic is checked without hitting a live account every time.
• The normalized schema as typed models, covering core banking and the Dirigo Investing positions under one account identity.
• Webhook-style emitters you can point at your own queue when new postings arrive, for teams that want push rather than polling.
• An OpenAPI description of the surfaces we map, and a short protocol & auth-flow report covering the token chain and error cases.
• Interface documentation plus data-retention and consent-logging notes for how the feed should be operated.

The OpenAPI spec and auth report matter, but they are reference material. What you actually deploy is the client and the runner.

Authorized ways into the data

Three routes genuinely fit this app. They differ in coverage and in how much they track app releases.

Member-consented interface integration

We analyze the app's own authenticated traffic, with the member's authorization, and reproduce the calls in code. Reachable: everything the member sees, including the investing tab. Effort is moderate; durability means we re-validate when the app ships a release, which we account for in maintenance. This is the route we would recommend here, because it is the only one that covers the full feed end to end.

Aggregator / open-finance consent link

Where a member prefers to link the account through a data aggregator, core balances and transactions can flow that way. It is durable and read-focused. Coverage depends on whether the aggregator already supports this specific credit union, and the brokerage tab generally sits outside that scope, so we treat it as a complement rather than the whole answer.

Native export fallback

Online banking can produce downloadable statements and transaction files. For a low-frequency batch load, that is the cheapest path, and we wire a parser for it. It will not give you near-real-time postings, but it is a sturdy backstop.

For most buyers the first route does the heavy lifting and the third is the safety net; we add the aggregator link only when a member relationship calls for it. Access for whichever route you pick is arranged with you during onboarding.

Member consent and the US data-rights picture

Dirigo FCU is a federally chartered credit union, so it sits under NCUA oversight, and member accounts carry the usual consumer protections. The dependable legal basis for an integration is straightforward: the member authorizes access to their own data, that authorization is recorded, and access stays scoped to what was agreed.

The federal open-banking rule does not change that today. The CFPB's Section 1033 Personal Financial Data Rights rule — the rule that would give consumers a formal right to their financial data through third parties — is currently enjoined and has been sent back to the agency for reconsideration, so it is not in force and its compliance dates are stayed. We treat it as the forward-looking piece: build on member consent now, and keep the design ready to ride 1033 if a revised rule lands. One extra wrinkle is specific to this app — the Dirigo Investing data comes from Unifimoney, a separate RIA the credit union says is not affiliated with it, so consent for brokerage holdings is scoped on its own rather than folded into the banking consent.

How we operate, regardless of route: authorized or user-consented access only, access logged, data minimized to what the integration needs, and an NDA where the engagement calls for one.

What we plan around for this build

A few things about Dirigo FCU specifically shape the work. We handle these as part of the build, not as conditions you have to satisfy first.

• Two upstreams, one member. Core banking and the Dirigo Investing tab are different backends — the latter is Unifimoney's. We model both, reconcile them under a single member identity, and keep their consent scopes separate so brokerage data never rides on the banking grant by accident.
• Business roles are not single-holder. The business side has multi-user logins with full versus view-only access and per-user transaction limits. We map that permission matrix so the integration only reads and acts on what a given login is actually entitled to, instead of assuming one all-powerful account holder.
• Deposit and clearing states. Mobile deposits move through submitted, hold, and cleared. We capture those transitions so a synced balance reflects pending versus available, rather than reporting a number that has not settled.
• No dependency on a named vendor. The credit union does not publish which digital-banking platform powers the app. Because we work from the live member session, identifying the platform is not on the critical path. Access is arranged with you — against a consenting member account or a test login you provide.

Screens we worked from

Store screenshots of the app, used to confirm which surfaces exist before mapping them. Tap to enlarge.

Other credit-union apps in the same integration bucket

If you are aggregating accounts across more than one institution, these sit in the same category — each holds the same kind of member-authenticated records, so the same integration pattern carries over. Listed for context, not ranking.

• Maine Savings — Maine credit-union app with balances, transfers, mobile deposit and bill pay behind a member login.
• Maine State Credit Union — Augusta-based app covering balances, deposits, transfers and a credit-score view.
• cPort Credit Union — Portland, Maine credit union with standard mobile balances, history and transfers.
• Evergreen Credit Union — Portland, Maine member app with the usual account and payment surfaces.
• Alternatives FCU Mobile — New York credit-union app holding account, transaction and transfer data.
• Navy Federal Credit Union — large national app with deep transaction history, cards and loans.
• PenFed Mobile — national credit union covering deposits, loans and transfers per member.
• DCU Digital Banking — Digital Federal Credit Union's app with accounts, payments and transfers.
• BECU Mobile — Washington-state credit union with balances, history and deposit capture.

What we checked, and when

Worked through the credit union's own mobile-app and Dirigo Investing pages for the feature set and the Unifimoney relationship, the App Store and Google Play listings for platform and identifiers, and current legal and CFPB sources for the Section 1033 status. Reviewed on 15 June 2026.

• Dirigo FCU — Mobile Banking App features
• Dirigo FCU — Dirigo Investing (Unifimoney)
• CFPB — Personal Financial Data Rights reconsideration
• Section 1033 — rule enjoined and under reconsideration (legal alert)

Written by OpenFinance Lab's interface-engineering desk — engineering notes, 15 June 2026.

Questions integrators ask about Dirigo FCU

Can you backfill years of a member's Dirigo FCU transaction history, or only recent activity?

We pull as far back as the account history exposes, one account at a time, walking the records page by cursor. The first run is a bulk backfill; after that we keep the ledger current with smaller incremental syncs. Those are two separate jobs, and if a backfill is interrupted it resumes from the last cursor rather than starting over.

Does the Dirigo Investing brokerage data come through the same path as checking and savings?

No. The Dirigo Investing tab is powered by Unifimoney (Unifimoney RIA QOBZ, LLC), which the credit union states is not affiliated with it, so positions in stocks, ETFs and crypto come from a different backend than core banking. We model the two upstreams separately, scope consent for each, and reconcile them under one member identity.

Which US rules govern pulling this data while the open-banking rule is in flux?

The dependable basis is the member's own authorization to access their accounts. The CFPB's Section 1033 Personal Financial Data Rights rule that would formalize a data-access right is currently enjoined and back in agency reconsideration, so we build on member consent today and keep the design ready to move onto 1033 if and when it takes effect.

What does a first delivery for Dirigo FCU usually look like?

A runnable client for balances and transaction history, plus the backfill-and-sync runner and a test suite, typically inside one to two weeks. Access is arranged with you during onboarding, against a consenting member account or a test login you provide.

Getting a build going

A first build here is that runnable balances-and-history client with the backfill runner and tests — source you keep, billed from $300 and paid only after delivery, once you are satisfied with it. If you would rather not host anything, the same surfaces run as our pay-per-call hosted API, with no upfront fee and billing only for the calls you make. Either way you give us two things: the app name and what you want out of its data; access and any compliance paperwork are sorted out with you as part of the work. Tell us what you need at our contact page and we will scope it — most builds land inside one to two weeks.