Pulling linked-account and asset data out of Money Forward ME

One Money Forward ME account is a fan-in point: the app describes linking to roughly 2,451 banks, credit cards, e-money issuers, securities accounts and point programs (the vendor's own count, per its Play Store listing as of April 2025). For an integrator that is the appeal — instead of wiring each institution yourself, you read one normalized layer that already holds balances, transaction history, deposit and withdrawal records, securities holdings and accrued points across all of a user's linked sources. The work we do here is shipping a language client that reads that layer under the user's authorization and lands it in your schema.

Bottom line: this is an aggregation-layer read, not a single-bank connector. Money Forward ME does not stream every transaction the instant it posts — it refreshes linked institutions on a cadence — so the route we would actually take is an authorized, consent-backed pull with a delta cursor, packaged as a client you can run on a timer. Where a Japanese bank exposes its own FSA-registered open API, that connection rides the same OAuth-style consent the app itself uses; where it does not, the authorized interface-integration route covers the gap. Both are normalized to one shape before they reach you.

What Money Forward ME holds, in data terms

Mapped to the surfaces the app actually presents to a user:

Authorized routes into the linked-account data

Three apply to this app. We set up access for whichever we recommend as part of the engagement, working through it with you rather than handing you a checklist.

Open-API consent under the FSA regime

Japan's 2017 Banking Act amendment created the registered electronic payment intermediary category; the open-API obligation took effect in June 2018 and, per the framework summary we cite below, around 97% of banks had stood up REST/JSON APIs with OAuth 2.0 authorization by the 2020 deadline. Where a user's linked bank participates, the cleanest read is a consent grant against that bank's open API for account, balance and transaction information. Reachable: structured statements and balances. Effort: moderate, mostly consent plumbing. Durability: high — it is the regime's intended path.

Authorized interface integration of the aggregation layer

For sources without a clean open API, or to read Money Forward ME's own consolidated objects, we analyze the app's authenticated traffic — token acquisition, the account and transaction endpoints, pagination and refresh behavior — and rebuild it as a documented client under the account holder's authorization. Reachable: everything the user sees in-app. Effort: higher up front, since we map the auth chain and pagination. Durability: good, with a re-check step when the app updates.

User-consented credential / export fallback

Where neither fits a given institution, a consenting user can authorize a session-based read, and the app's own data-export paths cover bulk history. We treat this as a backstop for coverage gaps, not the spine.

For most builds we would lead on the second route — a normalized client over the aggregation layer — and graft the open-API consent path on for the banks that support it, because that combination gives the widest coverage from one codebase.

What you receive at handoff

The headline deliverable is code that runs, not a document set:

• A runnable Python or Node.js client that authenticates, pulls accounts/balances/transactions, and emits the normalized model — the piece you actually deploy.
• A cursor-based sync routine (first backfill, then incremental delta pulls) plus, if you want push semantics, a small webhook emitter that fires on new transactions so downstream systems do not re-scan.
• An automated automated test suite that asserts the field mapping against recorded sample payloads, so a change in the upstream shape shows up as a failed assertion during the build rather than as bad data later.
• Retry, rate and pagination handling tuned to how the aggregation layer responds under load.
• Then the reference material: an OpenAPI/Swagger spec for the normalized surface, a protocol & auth-flow report (token acquisition, refresh, cookie/consent chain as it applies here), interface documentation, and data-retention guidance.

A pull against the aggregation layer

Illustrative only — exact endpoint paths, field names and the auth handshake are confirmed during the build against the live surface, not guessed here. The shape is a consent-backed token, then a cursor pull of normalized transactions:

from openfinance_lab.moneyforward import Client

# Token obtained via the user-consented authorization grant
client = Client(access_token=consent.token, refresh_token=consent.refresh)

# First run: backfill; later runs: pass the saved cursor for a delta pull
page = client.transactions(since_cursor=state.get("cursor"))

for acct in client.accounts():
    print(acct.institution, acct.asset_class, acct.balance, acct.currency)

for txn in page.items:
    record(
        account_id = txn.account_id,
        booked_at  = txn.booked_at,        # ISO 8601
        amount     = txn.amount,           # signed minor units
        payee      = txn.payee,
        category   = txn.category,         # app's auto-category, passed through
    )

state["cursor"] = page.next_cursor        # persist for the next incremental run

# Token refresh is handled inside the client; a 401 raises
# AuthExpired so the caller can re-run the consent grant

How the records land in your schema

Mixed asset classes are tagged, not flattened, so a securities valuation is never confused with a settled card charge:

{
  "account": {
    "id": "acct_8841",
    "institution": "linked-bank-or-issuer",
    "asset_class": "deposit | card | securities | emoney | points",
    "balance": 482310,
    "currency": "JPY",
    "as_of": "2026-06-02T09:00:00+09:00"
  },
  "transaction": {
    "account_id": "acct_8841",
    "booked_at": "2026-05-30T00:00:00+09:00",
    "amount": -1280,
    "payee": "merchant string as imported",
    "category": "food",
    "source": "auto-import | receipt-scan"
  }
}

Consent under Japan's open-API regime

The governing frame is the Financial Services Agency's open-API regime, built on the 2017 Banking Act amendment and the electronic payment intermediary registration that took effect in June 2018 — not a US-style data-rights rule. Money Forward operates in Japan as a registered financial-services intermediary (the app's listing names Money Forward Home Co., Ltd. and a Kanto Local Finance Bureau registration). Practically, every read we build rests on the account holder's own consent: scoped to the accounts they choose, revocable, and time-bounded the way the bank's grant or the app session defines. We keep consent records and request logs, minimize stored fields to what your use case needs, and sign NDAs where the engagement calls for it. The Share Board feature is consent-scoped at the app level too, so a shared-finance integration only ever sees the accounts a member has chosen to expose.

Things we plan around for this build

Two specifics that shape the work, both handled on our side:

• Refresh cadence versus "real time." Linked institutions update on a schedule, so a naive poller either hammers the layer or misses movements. We design the sync around the app's notification events — large-movement and settlement alerts — using them as a hint to run an incremental pull, and fall back to a timed delta sweep so nothing is missed when no alert fires.
• Heterogeneous connectors behind one count. The ~2,451 linked services do not all behave identically; a securities connector returns holdings and valuations, an e-money wallet returns a stored-value balance, a bank returns booked statements. We tag each account with its asset class at ingestion and capture per-connector quirks in the documentation, rather than assuming one schema fits every source.
• App updates. Because part of the route reads the authenticated app surface, we include a re-check pass against the recorded samples whenever the app ships a release, and fold any field moves into the mapping in the same cycle.

Screens we mapped while scoping

From the public Play Store gallery — useful for seeing how balances, the household calendar and asset graphs are laid out before mapping fields.

Other money apps in the same orbit

Same Japanese personal-finance category; an integrator consolidating across them faces the same aggregation question, which is why a normalized client tends to outlast a per-app one.

• Zaim — long-running kakeibo app with bank/card linking and camera receipt scanning; holds categorized income and expense records.
• Moneytree — aggregation app known for broad institution coverage and an English interface; holds balances, transactions and loyalty-point data.
• OsidOri — built for couples and households; holds shared and personal account views with split-payment tracking.
• Dr. Wallet — receipt-centric, with human operators transcribing receipts for accuracy; holds itemized expense records.
• Mainichi Kakeibo — daily-entry household ledger focused on manual expense tracking.
• Rakuna Kakeibo — lightweight budgeting ledger for quick daily income/expense capture.
• Household account book (Kanahei) — simple categorized expense logging aimed at casual users.

Questions integrators ask us

Does the data arrive in one batch or stream as a feed?

Both shapes are buildable. Money Forward ME refreshes linked institutions on a schedule rather than pushing every transaction live, so the client we ship runs a cursor-based delta pull: a first backfill of historical statements, then incremental fetches keyed to the last seen booking. If you want a push edge, we wrap the poller behind a small webhook emitter on your side so downstream systems react to new transactions instead of re-scanning.

Which language client do you hand over?

Python and Node.js are the defaults; Go on request. Each ships with the consent/token handling, the normalized account-transaction model, retry and rate handling tuned to how the aggregation layer responds, and an automated test suite that checks the field mapping against recorded sample payloads.

Money Forward links 2,451 services — does the integration cover all of them?

The vendor's own count is roughly 2,451 linked services as of its April 2025 listing. We do not hard-code per-institution logic; we read the normalized account, balance and transaction objects the aggregation layer already exposes, so coverage follows whatever the user has linked. Where a specific bank's connector behaves differently, we capture that quirk in the connector notes rather than assuming every source is identical.

How are securities, e-money and point balances represented versus plain bank rows?

They sit alongside bank and card accounts as typed asset entries — holdings and valuations for securities, stored-value balances for e-money, accrued points for loyalty programs. The schema we deliver tags each account with its asset class so your downstream code can treat a securities valuation differently from a settled card transaction instead of flattening everything into one ledger.

Working with us

You give us the app name and what you want out of its data; we arrange the access, consent and any compliance paperwork with you as part of the build. A first usable client for Money Forward ME lands in about one to two weeks. Buy the source outright from $300 — runnable client, tests and docs delivered, and you only pay once you are satisfied with what arrived. Prefer no upfront cost? Call our hosted endpoints instead and pay per call as you use them. Either way, tell us the data you need and we will scope it: start a conversation on the contact page.

I checked the app's Play Store listing and description for its data surfaces and the 2,451-service figure, read Ozone's summary of Japan's open-banking framework for the FSA regime and the June 2018 electronic-payment-intermediary timeline, and skimmed the budgeting-app landscape for the related names. Reviewed 2026-06-02 by OpenFinance Lab · interface engineering. Sources, opened directly: Play Store listing, Ozone — Japan open banking framework, Open Banking Tracker — Japan (FSA), Money Forward user data guide.