Pulling a clean transaction feed out of Rolly's AI money tracker

Rolly AI Pty Ltd ships shared wallets that stay in real-time sync across phone, web, and macOS — which means a server-side ledger sits behind every account, not a local-only database. That ledger is the thing worth integrating. A consenting account holder, an authorized read of the sync traffic, and the per-transaction record comes out structured: amount, currency, category, the wallet it belongs to, and how it was entered. The native CSV export gives you a flatter copy of the same history for backfill. Everything below is about reaching that ledger cleanly and handing you source you can run.

Bottom line: the value here is a normalized, multi-currency transaction stream with wallet structure and entry-provenance attached, plus the budget and goal layer on top of it. The route we would actually run is the authenticated sync path that the web and macOS clients already use, seeded once from the CSV export so you start with full history rather than only new activity. The bank-connection feature adds a second, narrower question — whether you want Rolly's normalized view of those transactions or the raw institution feed — and that choice changes which consent regime applies, not the deliverable.

What Rolly keeps against an account

These rows reflect surfaces Rolly itself names on rollyapp.ai, its App Store listing, and its store description — not a generic budgeting checklist.

Routes that actually reach it

1 — Authorized integration of the sync path

The web and macOS clients read the same ledger the phone writes to, so an authenticated sync API exists and is the richest surface. With a consenting account we map the auth handshake and the wallet and transaction reads, then ship code that pulls incrementally. This is the most complete route — it carries wallet structure, currency, and entry provenance that the CSV drops — and it is the one we recommend as the backbone. Durability is medium: it tracks the app client, so it needs the contract check described further down. We arrange the consenting test account and any onboarding with you as part of the build.

2 — Native CSV export as the seed

Rolly's own import/export ("bring your data from other apps or export for your records") gives a point-in-time CSV. Effort is low and it is durable because it is a user-facing feature, but it is flat: no wallet membership, no per-wallet currency, no sync state. We use it to load history once, then let route 1 carry everything new.

3 — User-consented client access

Where a surface shows in the app but not in the sync responses, a consenting account drives the client and we read what renders. Slower and more brittle than route 1; we keep it as a fallback for the goal and budget views if they sit outside the core sync.

4 — Open-banking consent for the bank-linked subset

If what you want is the raw bank feed behind Rolly's bank-connection imports rather than Rolly's normalized copy, that data is reachable directly from the account holder's institutions under their local open-banking consent. Different regime, different freshness, same engagement. We scope this only when the raw institution feed is the actual requirement.

What lands in your repo

• An OpenAPI description of the sync surface we integrate — auth, wallet list, transaction read with the cursor parameter, and the receipt-detail fields.
• A protocol and auth-flow report: the token exchange, refresh behaviour, and the request signing or cookie chain as it actually works for this app.
• Runnable source for the key calls in Python and Node.js — authenticate, list wallets, page transactions, pull receipt detail, and parse the CSV seed into the same shape.
• A normalized transaction and wallet schema so multi-currency and shared wallets do not collapse into one list.
• Automated tests, including the contract check that flags a field rename after a Rolly client update.
• Interface documentation and data-retention guidance written against the consent footing below.

A sync pull, sketched

Illustrative shape only — the exact paths, header names, and token mechanics are confirmed against a consenting account during the build, not asserted here.

POST /auth/session
  { "email": "<consenting account>", "secret": "<handled in onboarding>" }
  -> 200 { "accessToken": "...", "refreshToken": "...", "expiresIn": 3600 }

GET /wallets            Authorization: Bearer <accessToken>
  -> 200 [ { "walletId": "w_19", "name": "Travel",
             "currency": "EUR", "shared": true, "members": 3 } ]

GET /transactions?walletId=w_19&cursor=<last>&limit=200
  -> 200 {
       "items": [
         { "id": "t_8841", "walletId": "w_19", "amount": -42.10,
           "currency": "EUR", "category": "Dining",
           "occurredAt": "2026-05-09T19:04:00Z",
           "source": "receipt_scan",
           "merchant": "Trattoria", "tax": 3.80, "tip": 5.00 } ],
       "nextCursor": "c_8842" }

# error handling: 401 -> refresh once via /auth/refresh, then retry;
# 429 -> respect Retry-After; cursor is the resume point, never re-page from zero

The shape we normalize to

Two compact records keep currency, provenance, and shared ownership explicit so downstream code never has to guess.

Transaction {
  id, walletId, walletCurrency,        // currency travels with the row
  amount, category, occurredAt,
  source: chat | voice | receipt_scan | bank_link | manual,
  merchant?, lineItems?, tax?, tip?    // present only for scanned receipts
}
Wallet {
  walletId, name, currency,
  shared: bool, memberCount,           // drives household de-duplication
  budgets: [ { period, target } ],
  goals:   [ { name, target, progress } ]
}

Consent and the data-protection footing

Work runs from a consenting account holder's authorization, with access logged and data minimized to the domains the engagement needs. The publisher is listed as Rolly AI Pty Ltd, an Australian company, so the operator sits under the Australian Privacy Act 1988 and the Australian Privacy Principles; account holders in the EU or UK additionally fall under GDPR and UK GDPR. Rolly's own policy already exposes export and the email-and-transaction record set, which is the consent surface we work within. For the bank-connected subset, the underlying institution data is governed by the account holder's local open-banking consent — in Australia that is the Consumer Data Right, administered by the ACCC and the OAIC; other markets apply their own scheme. Consent is revocable, scoped to named domains, and recorded; we sign an NDA where the engagement calls for one. Where a specific retention period or regulator obligation is not publicly stated, we say so rather than assert a number.

What we plan around in this build

These are the app-specific things we account for, handled on our side rather than handed to you as conditions:

• Each wallet carries its own currency. We attach the wallet's currency code to every transaction so a cross-wallet rollup never silently sums euros into dollars.
• A shared wallet means one transaction can appear for several members. We model membership and role so household aggregation counts that transaction once, not once per viewer.
• Receipt-scanned rows carry merchant, line items, tax, and tip; chat- or voice-logged rows do not. Those fields are optional in the schema and we backfill nulls instead of failing the parse.
• Entry provenance differs — bank-connected imports versus typed, spoken, or snapped. We keep a source tag so reconciliation and duplicate detection can trust the right rows.
• Cross-device sync is cursor-driven. We design the pull around that cursor so re-runs resume incrementally instead of re-paging the whole history.
• The iOS client was on version 14.1.1 at the App Store listing when we checked, and it updates often; we keep a contract check in the maintenance window so a renamed field surfaces as a failed test, not corrupted data.

Keeping the feed honest

The sync route is as fresh as the account — new transactions show up on the next cursor pull, so a short polling interval keeps it near real time. Receipt OCR fields can lag the bare transaction by a moment while the vision model finishes; we treat merchant and line items as eventually-consistent and reconcile on a later pass. The CSV is a snapshot, good for the one-time seed and audits, not for live data. We recommend the sync pull as the live spine and the CSV strictly as the backfill and a periodic cross-check.

Screens we worked from

Store screenshots reviewed while mapping the surfaces above. Select to enlarge.

What was checked, and when

We read Rolly's marketing site and feature copy, its privacy-policy landing page (last updated March 2026 per that page), and its US App Store listing (publisher Rolly AI Pty Ltd, iOS build 14.1.1 at the time of review), and cross-checked the Android package and release timing on AppBrain. Where a fact such as the bank-aggregation provider or an exact retention window is not disclosed, this page says so rather than guess. Mapped by the OpenBanking Studio integration desk — May 2026.

• rollyapp.ai — features, sync, and the bank-level-encryption statement
• rollyapp.ai/privacy-policy — publisher and policy-update date
• App Store listing — developer, version, and App Privacy data card
• AppBrain — Android package and release history

Where Rolly sits among money trackers

Same-category apps an integrator often unifies alongside Rolly. Named for ecosystem context, not ranked.

• YNAB (You Need A Budget) — zero-based budgeting with bank-linked accounts and a documented sync model.
• Monarch Money — aggregated accounts, net worth, and collaborative household budgets.
• Copilot Money — AI transaction tagging over linked accounts, Apple-first.
• PocketGuard — linked-account spend limits and bill tracking.
• Cleo — chat-driven budgeting assistant over connected bank data.
• Spendee — multi-currency wallets and shared wallets, close to Rolly's wallet model.
• Wallet by BudgetBakers — manual and bank-synced ledgers with CSV export.
• Money Manager (Realbyte) — double-entry style manual ledger with export.
• Goodbudget — envelope budgeting with shared budgets across devices.
• Emma — account aggregation with subscription and category tracking.

Questions integrators ask about Rolly

Does the CSV export carry the shared-wallet structure, or just a flat list?

The CSV is a flat, point-in-time dump. It does not carry wallet membership, the per-wallet currency, the receipt line items, or any sync state, so a multi-currency or shared household ends up as one undifferentiated list. That is why we treat the authenticated sync path as the spine of the integration and use the CSV only to backfill history before the live pull takes over.

Can you separate bank-connected transactions from the ones I typed, spoke, or snapped?

Yes. Rolly lists bank connections, receipt scans, voice and chat entry as distinct ways a transaction lands, so each record carries a provenance we preserve as a source field in the normalized schema. Reconciliation and duplicate detection then know whether a row came from a linked institution or from manual entry.

Rolly's publisher is Australian — which rules govern the data we would be moving?

The App Store and the rollyapp.ai footer list the publisher as Rolly AI Pty Ltd, an Australian company, so the operator sits under the Australian Privacy Act 1988 and its Privacy Principles; EU and UK account holders also fall under GDPR and UK GDPR. The bank-connected subset of the ledger rides on the account holder's local open-banking consent — in Australia that is the Consumer Data Right, administered by the ACCC and the OAIC. We work from a consenting account and keep consent and access records throughout.

If Rolly ships a new app version mid-project, does the integration break silently?

The iOS client was at version 14.1.1 on the App Store listing when we checked, and this app updates often. We pin a contract check against the sync responses so a renamed or dropped field fails a test instead of quietly writing bad data, and a fix for that kind of drift fits inside the one-to-two-week cycle.

Two ways to engage. We deliver runnable source plus the interface documentation from $300, invoiced only after delivery once you are satisfied; or you skip the build fee and call our hosted endpoints, paying per call with nothing upfront. Either path runs on a one-to-two-week cycle, and the brief starts from just the app name and what you want out of Rolly's ledger — access and compliance are arranged with you along the way. Start at /contact.html.