What a Bank of Newington Mobile integration actually involves

Bank of Newington holds roughly $287M in assets across three Screven County branches, and its mobile app pulls a per-member view of those accounts plus any external accounts the user links. That second part matters: this is a small bank running an aggregating front end, not a money-center API stack, so the integration we would actually deliver lives on the member's own consent and on the wire format the mobile and web clients already speak.

Short version. One consenting member's session, mapped end to end, delivered as a runnable client. The half that originates inside Bank of Newington comes from the bank's member endpoints; the half that originates outside (the external accounts the member has linked) comes from the aggregator the PFM front end is wired into. We normalize them into a single feed downstream code can consume.

What data is actually on the wire

Routes we would actually take

Four are honestly on the table for a community bank app at this scale. We would lead with the first.

1. Member-consented direct integration of Bank of Newington's own endpoints. The member logs in the way they already do; we ride that session, talk to the same JSON the mobile client talks to, and ship the resulting client. Auth chain is recognizable to anyone who has worked a Banno-family front end before, but the cookie/timeout behavior is bank-specific and we map it on the wire, not from documentation.
2. Authorized interface integration of the mobile traffic. When you need the screens the web client does not render — geo-tags, attached images, the PFM rollups — we work directly against the mobile transport under the member's authorization. Slower to stand up than route 1, more durable for the metadata-heavy fields.
3. Aggregator-mediated read for the external-account half. The accounts the member has linked from outside Bank of Newington are not actually fetched by Bank of Newington at request time; the underlying call goes out through an aggregator the PFM front end is wired into. We treat that as a sub-integration with its own consent flow and its own failure modes.
4. Native export from Internet Banking statements. CSV/PDF month-end pulls. Useful as a low-frequency backstop for historical reconstruction, not as the live spine of an integration.

For most consumers of this brief, route 1 is what they actually want, with route 3 layered in where the household view matters. Route 2 comes in when the customer specifically needs the in-app metadata that does not surface on the web side. We say which one we would build before quoting; the recommendation depends on the data, not on the rate card.

Member consent and the US data-rights backdrop

Member authorization is the dependable basis. The only path the customer has to their own accounts is the Bank of Newington Internet Banking enrollment they already hold; the integration runs against that, with a written authorization on file at the member-account level. Consent scope, expiry, and revocation are handled in the engagement — a single member, a single set of accounts, the access turned off the way the member would turn it off through the bank.

The CFPB §1033 Personal Financial Data Rights rule is the relevant forward-looking US piece. As of this writing it is enjoined and back in agency reconsideration, so the studio does not treat any §1033 obligation as currently governing for an integration against a bank in Bank of Newington's tier. The dependable basis stays the member's own authorization. If a successor rule settles in a form that adds live obligations for community banks at this size, we re-baseline the integration at that point and update the consent record accordingly.

Notes from the build side

Three things we account for on a build like this, written from our side of the table — they shape how we deliver, not what you have to do upfront.

1. The two halves of the feed have different shapes and different SLAs. The Bank of Newington-side endpoints return one envelope; the aggregator the PFM is wired into returns another. We normalize them in the delivered schema so the consumer sees one balance and one transaction stream per linked account, not two source-flavored ones, and we keep the two refresh cadences and two failure modes documented separately so on-call has a hope of triaging which side broke.
2. We pin parsers to the JSON shapes returned on the wire, not the labels on the screen. A Banno-family front end changes copy and CSS from release to release without touching transport; pinning the parser to transport keeps the integration quiet through cosmetic refreshes. The test suite included in the delivery flags the real thing — a structural change in a response payload — instead of catching a button rename.
3. Member metadata travels with the member's own auth context. Tags, notes, geo-tags, and attached check images are keyed to the member's own transaction ids inside the PFM store. The per-account fetch returns them alongside the standard fields under the consenting member's session; they are not reachable from any other context, and we do not represent that the integration can hand back another member's metadata. Access for the build is arranged with you during onboarding — typically one consenting account, run inside the studio environment.

Deliverables for this build

• An OpenAPI 3 specification covering the bank-side endpoints — auth chain, accounts list, balances, transactions with metadata, transaction-detail, alerts.
• A short protocol & auth-flow report — the multi-step login, the session cookie / token behavior on Bank of Newington's actual instance, idle-timeout and re-auth handling.
• Runnable client source in both Python and Node.js, structured so the consumer can drop it into a job runner without rewriting.
• A pytest / Jest test suite that runs end to end against the consenting member's account.
• Interface documentation written for a backend engineer reading it cold, not as a marketing artifact.
• A short data-retention and consent-record memo tuned for a US community-bank counterparty (member consent record, data minimization, encryption-at-rest expectations).

A sketch of the per-account fetch

Illustrative; field names and exact endpoints are confirmed on the wire during the build.

from bon_client import BoNSession

# Set up during onboarding against one consenting member.
s = BoNSession(member_id=AUTHED_MEMBER)
s.login(username, password)            # Banno-style multi-step, sets the session cookie

for account in s.accounts():
    # account.id, account.kind ('CHK'|'SAV'|'LOAN'|'CD'),
    # account.nickname, account.current_bal, account.available_bal
    txns = s.transactions(account_id=account.id, since='2025-11-01')

    for t in txns:
        # t.id, t.posted_at, t.amount, t.merchant_name, t.category,
        # t.geo  (lat/lng or None),
        # t.tags (member-authored), t.notes, t.attachments
        yield normalize(account, t)

# External, member-linked accounts go through the aggregator the PFM is wired into:
for link in s.external_links():
    for ext_acct in link.accounts():
        ext_txns = link.transactions(account_id=ext_acct.id, since='2025-11-01')
        for t in ext_txns:
            yield normalize(ext_acct, t, origin='external')

A 401 on the bank side typically means the session cookie has aged out — the client refreshes the multi-step login rather than silently dropping. A 5xx on the aggregator side is treated as transient up to a small bounded retry; the consumer downstream is told which side failed so it can replay just the missing half.

How we run the engagement

Source-code delivery for a build at this scale runs $300, billed after we deliver and you have signed off. The hosted alternative is pay-per-call against our endpoints — same code, no upfront fee, you pay only for calls you actually make.

Cycle is one to two weeks from kickoff. Access and authorization are arranged with you during onboarding — typically a single consenting member's credentials, run inside the studio's environment, with the resulting source delivered to your repository. To scope a specific build, get in touch through the contact page with the app name and the data you need; we come back with the route, the timeline, and the price before any work starts.

Nearby apps in the same Georgia community-bank cluster

Apps a buyer comparing integration targets often looks at alongside Bank of Newington Mobile. Listed neutrally; same-category, not ranked.

• Queensborough National Bank & Trust mobile — long-running Georgia community-bank app with a comparable PFM-style member view.
• Pineland Bank — South Georgia community bank, similar small-bank mobile front end across multiple branches.
• Georgia Community Bank (GCB Mobile) — closer to Bank of Newington in footprint and feature mix.
• Ameris Bank mobile — a larger Georgia regional whose app exposes a broader feature surface.
• United Community Bank — Southeast regional with a mobile app covering Georgia, the Carolinas, and Tennessee.
• Renasant Bank mobile — Mississippi / Southeast regional with a community-bank-style app.
• Delta Community Credit Union — large Georgia credit union, separate ecosystem but a frequent comparator.
• Georgia Heritage Federal Credit Union — Savannah-area credit-union app with the same household-view ambitions.
• Heritage Southeast Bank — community-bank umbrella with a similar app pattern.

Questions integrators have asked about this app

The app aggregates external accounts inside its own UI. Are those external balances reachable through the same integration as the Bank of Newington-held accounts?

They are reachable but through a different sub-route. The Bank of Newington-side balances and transactions come back from the bank's own member endpoints. The external balances are pulled by the aggregator the Banno-style UI is wired into; the consenting member's link records sit in the PFM store, but the actual fetch travels through the aggregator. We deliver both as one normalized feed so the downstream code does not have to care, but the underlying credentials, refresh cadence, and failure modes for the two halves stay separate.

Bank of Newington is a $287M, three-branch institution. Does the smaller size change what is reachable?

Not in the way most people expect. A community bank this size effectively rides the platform vendor's front end (a Banno-style PFM stack in this case), so the wire format and the auth chain are recognizable across many small US banks. What does differ is how often the front end gets cosmetic updates and how forgiving the session handling is; we account for those during the build.

Where does §1033 leave a community bank this size — anything we should plan around?

§1033 is the unsettled US piece — there is no live federal data-rights obligation we are relying on here. The integration's dependable basis is the consenting member's own authorized access to their own accounts under Bank of Newington's existing Internet Banking terms. If a successor rule settles in a form that adds obligations for institutions in this size tier, we re-baseline at that point.

Custom transaction metadata (tags, notes, geo-tags, attached photos) — that is user-generated. Is any of it actually reachable through the integration?

Yes, where the member who created it is the same member whose session is running the integration. The PFM store keys these records to the member's own transaction ids, so the per-account fetch returns them alongside the standard fields. They are not visible from a different member's auth context, and there is no route to bulk metadata across the bank's user base — only what one consenting member's own session can see.

Sources and review

This brief draws on Bank of Newington's own materials, the FDIC's filings on the institution, the app's store listings, and the current CFPB position on the Personal Financial Data Rights rulemaking. Checked May 2026 against the live pages.

• Bank of Newington — Mobile Banking
• FDIC BankFind Suite — Bank of Newington (certificate 5704)
• Apple App Store — Bank of Newington Mobile
• CFPB — Required Rulemaking on Personal Financial Data Rights

Mapping prepared by OpenBanking Studio · integration desk · 2026-05-24.