What it takes to put The Bank of Clarendon behind an API

The Bank of Clarendon runs about $369 million in assets, per its FDIC profile, and the consumer app sitting behind those accounts is doing real work: balances, a tagged transactions feed with receipt photos, statements, transfers, bill pay, P2P, remote deposit, debit-card controls, alerts, and an aggregator pane for accounts at other institutions. That is a richer data surface than the asset size suggests. A working integration on this engagement maps those surfaces to a documented interface against the accountholder's own authorized session, so any one of them can be reached from another system on a known schedule.

Data inside the consumer app

The table below is the surface set a builder cares about, written from the labels the app and portal actually use rather than a generic banking vocabulary.

Two practical routes into the portal

There are two routes worth quoting for this app, and a third worth mentioning for one narrow case.

1. Consent-based authorized access on the portal session chain

The accountholder authorizes us, under an NDA where they ask for one, to drive the same session the mobile app and the web portal drive. We hold the credential, complete the step-up where the portal asks for one, and exercise the endpoints behind each tab. Every surface in the table above is reachable this way. This is the route the build runs on.

2. Aggregator-mediated read via Plaid, MX or Finicity

If the customer's use case is satisfied by current balance plus a transactions feed, an aggregator connection is a simpler operational footprint and we will use it. Statements, transfer initiation, alert configuration, RDC payloads and card controls are not part of that surface, so anything past balances-and-transactions falls back to route 1.

3. Native PDF statement export, for audit-only scopes

Where the use case is “monthly statements into the accountant's vault” and nothing else, the integration is the statements section and a renamer. It is a cheap scope and worth pricing separately when that is genuinely all the customer needs.

Route 1 carries the build because the surfaces customers actually ask for, statements and write actions in particular, do not live in the aggregator path.

Engineering judgment calls on this build

Three specifics shape the schedule and the operator runbook.

Session lifecycle and device binding

The portal pins sessions tightly. Tokens are short-lived, the login is bound to a device fingerprint, and an idle session expires faster than a desktop user would notice. We design the credential-refresh cycle and the sync cadence around that window, with the result that the accountholder sees re-auth prompts on a known cadence instead of at unpredictable times.

Vendor-platform churn on the front end

Community-bank portals run on third-party platforms that push UI updates on their own schedule. Logins move, DOM ids change, MFA prompts shift order. The build ships with a small nightly canary that runs the critical path against a consenting account; the morning the platform pushes a change, the canary fails first and the patch goes out under the standing engagement, not a fire drill.

Risk-based step-up

The portal can step up to SMS or device-binding under risk conditions even after a successful login. The integration is built around that fact rather than against it: the auth flow expects an OTP source, the operator runbook says when to expect one, and the credential-handling protocol with the accountholder routes the prompt to a phone we can answer through.

None of the above is a precondition the customer has to clear before kickoff. Access, credentials and any sponsor coordination are arranged during the first few days of the engagement, with the accountholder or the institution as appropriate.

Authorization, §1033, and where the law sits

The Personal Financial Data Rights rule (12 CFR Part 1033) was finalized by the CFPB in late 2024 and would have been phased in by tier. It has since been enjoined in Forcht Bank v. CFPB, No. 5:24-cv-304-DCR (E.D. Ky.), and reopened by the Bureau for reconsideration through an advance notice of proposed rulemaking. As of May 2026 it is not in force and the compliance dates are set to be extended. For a community bank in Bank of Clarendon's size class, that simply means §1033 is not where the dependable basis for this work comes from today; it is the forward-looking piece.

The dependable basis is the accountholder's own authorization under FFIEC third-party guidance on consumer-permissioned data sharing: a written consent record we keep with the customer, an NDA where the customer or the bank asks for one, data minimization on the wire so nothing past the agreed surface is pulled, an immediate revocation path that takes effect on the next sync, and audit logging on every authenticated call. If §1033 settles into something the studio can ride on later, we will move the integration onto it. The interface contract does not change either way.

What the build hands back

A Bank of Clarendon engagement ships the following, all written for the surface set the customer scopes rather than for a generic bank:

• An OpenAPI 3 specification for the endpoints actually built, with each path tied back to the corresponding screen or section of the consumer app.
• A protocol and auth-flow report covering the session chain, token lifecycle, device-binding behavior, MFA step-up handling, and the request and response shape of each endpoint, with field-level notes.
• Runnable source for the priority endpoints in Python or Node, the customer's choice, with a small CLI to drive it and a Docker image so it runs on day one.
• An automated test suite: auth round-trip, statement fetch, transactions delta, transfer simulation against a consenting account, and a canary script for the critical path.
• Operator documentation: runbook, error catalog, sync schedule, expected re-auth cadence, and an incident playbook for when the portal front end shifts.
• A compliance handover packet: consent template, retention policy, deletion-on-revoke procedure, log schema.

The customer brings the app name and what they need from the data. Everything in the list above is on us.

A worked example: pulling a statement

This is the shape of the statement-fetch flow under route 1. The exact field names are confirmed during the build against a consenting account; the structure is what the operator runbook documents.

# illustrative — exact field names confirmed during the build
# Bank of Clarendon, FDIC cert 15671 (per BankFind)

session = boc_portal.login(
    username=cred.username,
    password=cred.password,
    device_id=cred.device_id,        # the portal binds to a device fingerprint
)

# step-up arrives on a risk decision, not on every login
if session.requires_otp:
    otp = otp_source.read(timeout_s=120)
    session.complete_otp(otp)

accounts = boc_portal.accounts.list(session)

for acct in accounts:
    stmts = boc_portal.statements.list(
        session=session,
        account_id=acct.id,
        since="2025-01-01",
    )
    for s in stmts:
        pdf = boc_portal.statements.download(session, s.id)
        sink.put_pdf(
            path=f"boc/{acct.id}/{s.period_end}.pdf",
            body=pdf,
        )
        sink.put_record({
            "institution":   "the-bank-of-clarendon",
            "fdic_cert":     "15671",
            "account_id":    acct.id,
            "account_label": acct.label,         # the bank's display name
            "period_start":  s.period_start,
            "period_end":    s.period_end,
            "balance_close": s.balance_close,
            "doc_uri":       f"boc/{acct.id}/{s.period_end}.pdf",
        })

# error handling worth naming explicitly:
#   SessionExpired      -> refresh credential cycle, log to runbook
#   StepUpRequired      -> route OTP to consenting accountholder
#   DocumentNotReady    -> the bank publishes statements on the 5th; retry next window

Three scenarios this fits

• Small-business bookkeeping. A Manning-area contractor with three BOC accounts wants nightly transactions and balances into QuickBooks, on their own consent. Route 1 with a 30-minute pull during business hours, scoped to balances and transactions only.
• Treasury cash position. An SC family business with operating, payroll and reserve accounts at BOC wants a morning cash-position email and a feed into a CFO dashboard. Route 1, scoped to balances, with internal-transfer simulate as an optional second phase.
• Accountant document vault. A regional CPA firm wants monthly statements for a roster of clients who bank at BOC, into a shared retention system. Route 3 is enough; pay-per-call is usually the cheaper model here.

Freshness and the canary

For most scopes the default cadence is a balances and transactions pull every 30 minutes during business hours, statements monthly on the 5th once they post, and an alerts and card-status check at the start of each business day. Re-auth windows under typical risk posture sit at roughly 60 to 90 days for the accountholder; the runbook tells the operator when the next prompt is expected so it does not arrive as a surprise. The nightly canary covers login, balances, statements list, and a transactions delta; one failed canary triggers an alert, two consecutive failures pause the sync until the patch ships.

Other community-bank apps in the same engineering family

These are real US community and regional banks with mobile portals that look, technically, very much like the Bank of Clarendon build. The pattern carries between them; the credentials and the customer-side specifics do not.

• Anderson Brothers Bank — Pee Dee, Coastal and Low Country SC. Same domain set; same consent-based portal route.
• Palmetto State Bank — Hampton, SC, founded 1907. Mobile app covers balances, transfers, RDC, bill pay.
• First Palmetto Bank — Camden, SC, twenty-two locations across the state. Comparable surface set.
• Conway National Bank — Conway, SC. Community bank with mobile RDC and statement access.
• South State Bank — SC-headquartered regional. Same data domains at a much larger asset base.
• First Citizens Bank — NC and SC franchise. Same engineering pattern, much wider footprint.
• Synovus — Southeast regional with a community-bank lineage and a similar consumer-app surface.
• Truist — large SE regional; useful as a yardstick for what surface coverage looks like at the other end of the size scale.

Questions integrators ask about this app

Will a Plaid or MX connection get me the same data?

For balances and a transactions feed, often yes. For statements, internal transfers, alert configuration, RDC payloads, and debit-card controls, the aggregators do not have a stable surface for a bank of this size, so the build runs on the accountholder's own consented portal session and reaches all of it.

Can the integration push transfers, or is read the limit?

Internal transfers between the accountholder's own Bank of Clarendon accounts are reachable as a write surface. External rails (bill pay vendor, P2P partner) are write surfaces too, but with their own consent prompts and per-vendor caps. We map the write set with the customer before quoting because the abuse and audit profile is different from read-only.

What happens when the portal changes its login flow?

Community-bank portals run on a vendor platform that ships UI updates on its own cadence. The build includes a nightly canary that runs the critical path against a consenting account; the first morning the login DOM shifts, the canary fails, the integrator gets the alert, and the patch goes out under the standing engagement instead of a fire drill.

How does this work for an accountholder who uses MFA on every login?

The auth flow is built around the accountholder, not around hiding the prompt. SMS or device-binding step-ups arrive on their phone, they answer, and the session refreshes. The schedule is tuned so the prompt arrives at a known cadence rather than at random moments, and the operator runbook documents exactly when to expect one.

How this brief was put together

Sources checked for this page: the app description on the Google Play Store; the FDIC BankFind record for certificate 15671; the Federal Register notice opening reconsideration of the Personal Financial Data Rights rule (Aug 22, 2025); and the Cozen O'Connor compliance alert summarizing the Forcht Bank injunction and the reconsideration status. The mobile portal host at my.bankofclarendon.bank was reached as an unauthenticated visitor only.

• Google Play — The Bank of Clarendon
• FDIC BankFind — The Bank of Clarendon (cert 15671)
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 22, 2025)
• Cozen O'Connor — Section 1033 Compliance Date: Open Banking Rule Enjoined and Under Reconsideration

Reviewed May 2026 by the OpenBanking Studio integration desk.

Talk to us

Source-code delivery for a Bank of Clarendon integration starts at $300, paid only after we hand the code over and you have run it on a consenting account. The other model is a pay-per-call hosted endpoint, with no upfront fee, billed by the call once the integration is live. Either way the cycle from kickoff to delivery is one to two weeks for a scope like this, and access, credentials and any compliance paperwork are arranged with you during the first days of the engagement — not handed back as a checklist before we start. Send the app name and a sketch of the data you want at /contact.html and we will reply with a scope.

Mapping reviewed 2026-05-24.