Reaching the per-child spending, allowance, and balance data inside Till

Transaction and account data inside Till

Every Till sub-account — one per child in the family — stores its own transaction ledger, balance, savings goals, and allowance configuration. The parent account holds a family-level view plus wallet and transfer records. Here is what an integrator can expect to reach:

Routes to Till's parent-and-child records

Three routes genuinely apply to Till. They differ in what data they expose and how durable they are.

Aggregator-mediated access (Plaid → Coastal Community Bank)

Coastal Community Bank is a Plaid-supported institution (per openbankingtracker.com). Through a Plaid integration, you can pull raw bank-level balances and transactions. The limitation: Plaid returns Coastal Community Bank account data, not Till-native structures. Allowance schedules, savings goals, spending-category breakdowns, and per-child segmentation are absent at this layer.

Authorized protocol analysis of the Till mobile app

The richer route. Till's app communicates with its backend over HTTPS; analyzing that traffic under the account holder's own credentials exposes the full data model — per-child ledgers, allowance rules, savings goals, spending insights, card-lock state. This is the route we build. Access is arranged with the client during onboarding; the integration runs against a consenting account.

User-consented credential access

Direct session replay under the parent's authorization. Useful when aggregator coverage is thin or when protocol analysis needs session tokens as its input layer. The scope is the same as what the parent sees in the app.

Protocol analysis of the app traffic is our recommended build for Till, because it is the only route that surfaces the family-banking-specific data — allowances, savings goals, per-child spending categories — that distinguishes Till from a generic checking account. Plaid serves as a supplementary channel for raw balance confirmation.

Consent and the US data-rights landscape for Till accounts

Till is a US fintech; the accounts are domiciled at Coastal Community Bank in Washington state. The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is not in force — enforcement has been enjoined by a federal court (Eastern District of Kentucky) while the agency reconsiders the rule, per a CFPB status page. Where that rulemaking lands will shape future obligations, but it does not govern today.

The dependable basis is the account holder's own authorization. The parent consents to data retrieval, scoped to specific domains. We operate under that consent with full audit logging, data minimization (only the fields the client needs), and NDA where required. Coastal Community Bank's Gramm-Leach-Bliley privacy notice governs what the bank shares through its own channels; our route operates under the account holder's direct authorization.

What a Till build includes

Concrete deliverables, tied to the data surfaces described above:

• OpenAPI specification covering discovered endpoints — transaction list, balance query, allowance configuration, savings-goal state, card-status check.
• Protocol and auth-flow report: how the app authenticates (token chain, refresh mechanics, session lifetimes as observed during the build).
• Runnable source code (Python or Node.js, your choice) for each endpoint, with error handling and rate-limit awareness baked in.
• Automated test suite validating each endpoint against a consented session.
• Interface documentation: field-by-field mapping of every response payload, including data types, nullability, and edge-case notes (pending vs. settled transactions, zero-balance children, inactive allowance schedules).
• Compliance and data-retention guidance specific to Till's US/FDIC context.

Sample request: child transaction ledger

# Illustrative — exact paths and fields confirmed during the build

GET /api/v1/children/{child_id}/transactions
Authorization: Bearer {session_token}

# Response (trimmed)
{
  "child_id": "ch_9f2k...",
  "child_name": "Jamie",
  "transactions": [
    {
      "id": "txn_8a1c...",
      "merchant": "Target",
      "category": "shopping",
      "amount_cents": -1499,
      "currency": "USD",
      "status": "settled",
      "timestamp": "2026-06-04T14:22:07Z"
    },
    {
      "id": "txn_3b7e...",
      "merchant": "Spotify",
      "category": "subscriptions",
      "amount_cents": -599,
      "currency": "USD",
      "status": "settled",
      "timestamp": "2026-06-02T09:10:44Z"
    }
  ],
  "balance_cents": 4520,
  "next_allowance": {
    "amount_cents": 1000,
    "frequency": "weekly",
    "next_date": "2026-06-08"
  }
}
      

The response nests per-child transactions alongside balance and the upcoming allowance disbursement — a shape you won't find in the Plaid layer. Exact endpoint paths and field names are mapped and documented during the build.

Engineering notes for Till's multi-child architecture

Till's data model splits at the child level. Each child profile has its own token scope and ledger partition. We map these during the build so the delivered integration returns per-child data streams rather than a merged family blob. Any downstream system that needs to distinguish one child's spending from another's gets that separation intact.

Allowance schedules in Till can be weekly, biweekly, or monthly, with optional chore-gating. We capture the full schedule configuration, not just the last disbursement, so consuming systems can project future cash flow and reconcile against actual transfers.

Fintech session tokens typically rotate faster than tokens in social or e-commerce apps. We build the token-refresh logic into the delivered source and document the expected rotation window, so the integration doesn't silently lose access overnight. The test suite validates refresh behavior explicitly.

End-to-end integration scenarios

Three real situations where pulling Till data makes operational sense:

• An accounting platform ingests each child's transactions nightly, normalizes them into the family's chart of accounts, and flags spending above a configurable threshold.
• A school or camp issues stipends through Till and needs a daily balance-and-transaction sync to reconcile against its internal ledger — the integration surfaces per-child balances without parent intervention.
• A family financial-planning app aggregates balances across Till, a parent's primary bank, and a college savings plan into a single dashboard with per-child breakdowns.

Till app screens

Family banking apps in the same space

Till sits in a growing category of family-oriented fintech apps. Each holds similar data structures — child accounts, transaction ledgers, allowance or chore systems — and an integration strategy that covers one often extends to the others with route-specific adaptation.

• Greenlight — the most feature-dense kids' debit card platform, with investing tiers, savings categories, and chore management. A natural co-integration target for families using both.
• Current — a broader family banking platform that also serves adults, with teen accounts, savings pods, and instant transfers.
• Step — targets older teens with a secured Visa card and FDIC-insured accounts. Its data model is simpler (no chore or allowance system), but the transaction ledger is detailed.
• FamZoo — a prepaid-card system with a virtual family bank model, including IOUs, parent-to-child loans, and interest simulation. More structured than most competitors.
• Acorns Early — formerly GoHenry, now part of Acorns, combining a kids' debit card with an investing component. The investment-account data adds a layer most kids' apps lack.
• BusyKid — leans into chore-tracking and work-based earning, with a direct stock-purchase feature for kids. Its data includes chore logs and investment positions alongside card transactions.
• Goalsetter — focuses on savings goals and financial-literacy quizzes alongside a debit card. Its quiz and goal data are unique to the category.
• Modak — a newer kids' banking app with a parent-managed debit card and savings features, growing in the US and Latin America.

Questions about integrating Till

Does Till store per-child transaction history separately, or is it aggregated under the parent?

Each child card carries its own transaction ledger, balance, and savings-goal state. The parent dashboard aggregates these into a family view, but the underlying records are per-child. Our integration preserves that separation — you receive each child's data as a distinct stream, keyed by child profile ID.

Can the integration capture allowance schedules and savings-goal progress, not just card transactions?

Yes. Allowance rules (amount, frequency, source wallet), savings goals (target, current balance, deadline), and chore-reward linkages are all part of the authenticated session state. The delivered source code covers these alongside the transaction ledger.

How does Plaid's connection to Coastal Community Bank factor into the route?

Plaid covers balance and transaction data at the bank-account level through Coastal Community Bank. It does not expose Till-specific structures like allowance schedules, per-child spending categories, or savings goals. We treat Plaid as a supplementary channel for raw account data and use protocol analysis of the app's own session for the richer, app-native fields.

What happens to data collection if a parent locks a child's Till card?

A locked card stops new purchase transactions, but the account state — balance, historical transactions, savings goals, allowance schedule — remains accessible through the authenticated session. The integration continues to pull existing records; new transactions simply stop appearing until the card is unlocked. Our sync logic flags card-lock status so downstream consumers know the gap is intentional.

Sources and review detail

This assessment draws on Till Financial's privacy policy, terms of service, the Coastal Community Bank Plaid connectivity listing, and the CFPB Personal Financial Data Rights status page. App-store listing data was reviewed on the Google Play Store.

For a Till integration, we deliver runnable source code from $300 — paid after delivery, once you've confirmed it does what you need. If you'd rather not manage code yourself, our pay-per-call hosted API lets you pull the data on demand with no upfront cost. The build takes one to two weeks. Tell us the app name and what you need from its data; access, credentials, and compliance are arranged as part of the engagement.