Reaching balances, loan positions and transfers inside the BCSB app

Behind the icon sits a member portal: checking and savings shown as both current and available, mortgage and auto-loan balances, scheduled transfers to other institutions, a bill-pay register, and check deposits that appear as processing the instant a photo is submitted. That is a dense per-member record, and it is the thing an integrator wants to mirror. Bristol County runs its online and mobile banking on COCC's platform — a New England core processor — which is the detail that decides how a login and a balance pull actually behave. This brief maps what the app holds, the authorized ways to reach it, and the source code we hand over.

What member data the app exposes

Each row below is a surface the app itself presents, named close to how the app names it. Granularity is what an integrator can realistically expect once a member has consented or authorized the work.

A worked example: listing accounts and reading a balance

The shape below is illustrative — field names and the exact token mechanics are confirmed against the live flow during the build, not asserted here. It shows the part that matters: a device-bound session, an account list that mixes deposit and loan types, and the current/available split the app surfaces.

# Illustrative — confirmed during the build, not a published contract
POST /cocc-dbank/auth/session            # device-enrolled login; Face ID resolves
                                         # to a stored credential, not a fresh password
  -> 200 { "session_token": "…", "expires_in": 900, "device_id": "…" }

GET  /cocc-dbank/accounts
  Authorization: Bearer <session_token>
  -> 200 {
       "accounts": [
         { "id": "chk-01", "type": "DEPOSIT",
           "nickname": "Free Checking",
           "balance_current": 2840.55, "balance_available": 2790.55 },
         { "id": "sav-02", "type": "DEPOSIT",
           "nickname": "Statement Savings",
           "balance_current": 15110.00, "balance_available": 15110.00 },
         { "id": "mtg-09", "type": "LOAN",
           "nickname": "Mortgage",
           "balance_current": 188204.13, "payment_due": "2026-07-01" }
       ]
     }

# Token refresh and breakage handling
def get_balances(client):
    r = client.get("/cocc-dbank/accounts")
    if r.status_code == 401:              # session aged out (~15 min)
        client.refresh_session()          # re-run device-bound auth, retry once
        r = client.get("/cocc-dbank/accounts")
    r.raise_for_status()
    return normalize(r.json()["accounts"]) # deposit + loan -> one schema
      

What you receive at handoff

These deliverables map to the surfaces in the table above, not a generic checklist.

• An OpenAPI/Swagger spec for the normalized endpoints — account list, balances (current and available), transactions, loan positions, transfer status, bill-pay schedule.
• A protocol and auth-flow report covering the COCC session, the device-enrollment step behind Face ID, and the token/cookie chain as it behaves on this app.
• Runnable source in Python or Node.js for the full path: authenticate, list accounts, read balances, page transactions, pull a statement.
• Automated tests that run against a consenting member account or a sponsor sandbox, including the loan-vs-deposit normalization and the session-refresh retry.
• Interface documentation plus data-retention and consent-logging guidance written around a US deposit institution.

Authorized ways into the account data

Three routes genuinely apply to Bristol County. Each is something we set up and run with you; access and onboarding are arranged as part of the project.

Consumer-permissioned consent (FDX / OAuth style)

The member authenticates through their own BCSB login and approves the specific data and the time window. Reachable: balances, transactions, account and loan identifiers. This is the most durable path because it survives front-end changes, and it is where US data sharing is heading. We stand up the consent flow and the token handling.

Authorized protocol analysis of the app's traffic

Under your authorization, we map how the app talks to the COCC backend and reproduce the calls. Reachable: effectively everything the app renders — including bill-pay schedules, transfer status, and the processing-deposit state that consented aggregation feeds often drop. Higher effort, and its durability tracks the portal front end, which is why a re-validation pass is part of the build.

Native member-portal export

Statement downloads (PDF, and machine-readable exports where the portal offers them) cover historical records and serve as a backstop for reconciliation. Lower coverage on real-time state, but cheap and stable for archives.

For a COCC-hosted community bank where the member already logs into the app daily, the consent route is the one I'd build the integration on — it is durable and clean. The catch specific to BCSB is that several high-value surfaces (loan payment-due detail, bill-pay timing, in-flight deposit status) live in the app but not always in a consented feed, so I'd cover those with authorized protocol analysis rather than pretend one route reaches all of it.

Whose permission the data rides on

Bristol County is a US deposit institution, FDIC-insured under certificate 23622 (per the FDIC BankFind record), so the relevant question is consent, not a foreign open-banking mandate. The dependable basis is the member authorizing access to their own accounts and authenticating through their own login. We keep consent records, log access, minimize the fields pulled to what the use case needs, and work under an NDA where the engagement calls for one.

The forward-looking piece is the CFPB Personal Financial Data Rights rule. It was issued in 2024, then enjoined in late 2025 and sent back to the agency for reconsideration, and its compliance schedule put the largest institutions first and community banks years behind — a schedule that is now paused, so no date binds a bank Bristol County's size today. We treat that rule as where US data access may go, not as current law, and we do not build the integration on an obligation that isn't in force. Member consent carries it either way.

Engineering details we plan around

Two things specific to this app drive the build, and we handle both:

• The COCC platform and its refresh. The bank has rolled its online banking through a COCC migration and a front-end refresh. We map the COCC session and device-enrollment flow so re-authentication and the biometric-backed token behave correctly, and we wire a re-validation pass that flags when the portal markup shifts rather than letting the pull fail silently.
• Current versus available, and loan versus deposit. The app deliberately separates current and available balances, and it mixes deposit accounts with mortgage and auto-loan accounts in one list. We model both balance fields so pending holds aren't conflated, and we scope the schema so a loan's payoff and a checking balance normalize cleanly side by side.
• Segment differences. Bristol County serves personal, business, municipal and commercial customers, and the data model differs across those. We scope per segment so a business cash-management view isn't built on a personal-account assumption.

Keeping the feed honest over time

A COCC front-end refresh or a session-timeout change is the usual cause of a quiet break. We design the sync around the consent-refresh window so it doesn't expire mid-run, set a polling cadence that matches how often balances actually move, and ship the re-validation check as part of maintenance so a markup change surfaces as an alert, not as stale numbers.

Screens we worked from

Store screenshots of the app, used to read the surfaces named above. Select one to enlarge.

Neighboring New England banking apps in the same map

If you're aggregating across the SouthCoast and Rhode Island, these sit in the same category as Bristol County and hold comparable per-member records. Named for context, not ranked.

• Rockland Trust — large Massachusetts community bank app with balances, transfers, deposit and bill pay; a common second connection in the region.
• BankFive — SouthCoast Massachusetts and Warwick, RI; personal and business mobile banking with mobile deposit.
• HarborOne Bank — Brockton-based, with branches across Rhode Island; checking, savings and a range of loan products in-app.
• Centreville Bank — Rhode Island and Connecticut community bank app covering deposits, loans and card accounts.
• BayCoast Bank — MA and RI, with both consumer and a separate business mobile app holding account and transfer data.
• Mechanics Cooperative Bank — a Taunton neighbor of BCSB; mobile banking and mobile deposit across SouthCoast branches.
• Navigant Credit Union — Rhode Island credit union app with account views, transfers, bill pay and check deposit.

What we checked

Surfaces were read from the app's store listing and the bank's own digital-banking pages; the institution facts and platform come from the sources below, opened during the review on 11 June 2026. Identifiers and asset figures are quoted as the sources state them, not asserted independently.

• FDIC BankFind — Bristol County Savings Bank, certificate 23622
• Bristol County Savings Bank — Our History (1846 founding, Beacon Bancorp)
• COCC — Bristol County Savings Bank partnership for core, online and mobile banking
• CFPB — Personal Financial Data Rights reconsideration (Section 1033 status)

OpenBanking Studio integration desk · mapping reviewed 2026-06-11.

Questions integrators ask about Bristol County

Does the consumer-permissioned route capture mortgage and auto-loan balances, or only checking and savings?

Both. The app lists mortgage, auto-loan and other balances alongside checking and savings, and those loan positions arrive as a separate account type from deposit accounts. We normalize them into the same schema so a debt figure and a cash figure sit side by side, each tagged with its account class.

BCSB moved its online and mobile banking onto COCC. Does that change how you reach the data?

It shapes the build. The app authenticates against a COCC-hosted digital banking backend, so the session, the device enrollment that backs Face ID, and the token chain follow COCC's flow rather than a generic one. We map that flow during the engagement and add a re-validation pass for when the portal front end is refreshed.

With Section 1033 enjoined, what is the legal basis for pulling a BCSB member's data?

The member's own authorization. The CFPB Personal Financial Data Rights rule is enjoined and back in reconsideration, so it is not the basis anyone relies on today. For a community bank this size, consumer-permissioned access — the member consenting and authenticating through their own login — is the dependable footing, and that is what the integration is built on.

Can you surface pending mobile-deposit status, not just posted balances?

Yes. The app shows a check deposit as processing the moment it is submitted, before it posts. That processing state is its own surface, and we capture it through authorized protocol analysis of the app's traffic so a downstream ledger can reconcile a deposit before it clears.

You give us the app name — Bristol County Savings Bank — and what you want out of its data; access, sandbox or consenting-account arrangements and compliance paperwork are handled with you as the project runs. Most builds at this scope land in one to two weeks. Source-code delivery starts at $300: runnable source plus documentation, paid only after delivery once it works for you. Prefer not to host anything? The same surfaces are available as a pay-per-call hosted API, where we run the endpoints and bill by call with nothing upfront. Tell us which fits at /contact.html and we'll scope it.