Skip to content

Tokyo Star Bank — extraction approach

Status: TSB is the single largest banking blind spot in the repo — holds the ¥780M Mita mortgage, receives Mita rental income, pays property operating expenses, and is the GK's primary operating bank. None of this transaction-level history is in the repo, in Xero, or in Monarch. This doc lays out paths to fix that.

Why TSB is a special case

  • Japanese bank. US/CA aggregators (Plaid, MX, Finicity, Yodlee) don't cover it. Monarch coverage map confirms this gap.
  • Japanese-language online banking UI. Browser automation would need to handle 日本語 form labels, possibly Japanese error messages.
  • Geo-restrictions likely. Japanese banks frequently block non-JP IPs at the login layer for retail customers. Even with a JP-IP'd user-agent, additional verification may trigger.
  • 2FA. TSB online banking uses one-time passwords (SMS or token-card; depends on Austin's enrollment).
  • Account is GK-owned, not personal. Adds a corporate-account-access layer that retail web automation may not handle cleanly.

Five viable paths, ranked

Lowest-effort, lowest-risk path to closing the gap.

  1. Once a month, Austin (or whoever has TSB credentials) signs in to TSB online banking on a regular browser, downloads the most recent transaction CSV / PDF statement, and drops it into ~/projects/renfroe-holdings/source-data/tokyo-star-bank/<YYYY-MM>/.
  2. A repo-side ingestion script parses the CSV (or OCRs the PDF if no CSV is available), produces a normalized markdown summary, and stores the canonical txn list under source-data/tokyo-star-bank/<YYYY-MM>/transactions.md.
  3. Monthly summary journals into Xero RFH org under the Renfroe Holdings GK Entity tracking category, USD-translated at month-end FX rate (Bank of Japan reference rate or BLS H.10).

Pros: zero credential exposure to automation, no JP-IP requirement, no 2FA brittleness. Same pattern as the JME monthly packets.

Cons: Austin remembers to download monthly. If Austin forgets, gap reopens.

Time to wire up: ~2 hours (parser + ingestion script + Xero summary journal template). Can be built without any TSB credentials in hand — start when the first CSV arrives.

Path 2 — Japanese accountant relays the data

If the Japanese accountant (per context/entities.md § Renfroe Holdings GK, name TBD) already pulls TSB transaction history for their monthly book-keeping, ask them to send a copy.

Pros: they're already doing the work; minimal incremental ask. Their normalization is likely already aligned with Japanese tax categorization.

Cons: unknown turnaround cadence; format is whatever the accountant uses.

Action: add to todo/for-advisors.md § Japanese accountant — "Provide monthly TSB transaction export (CSV preferred; PDF acceptable)."

Path 3 — Browser automation via Playwright on an Apple/Mac host

If we want this fully self-serve, the cleanest implementation is Playwright on Mac (per the mac-playwright MCP that's already wired up to the Mac Mini at the W3603 site, per global memory). The Mac would:

  1. Run a scheduled Playwright script under launchd or a cron (every Monday at 04:00 JST).
  2. Sign in to TSB online banking with creds from Vaultwarden (renfroe-holdings/tokyo-star-bank — would need to be created).
  3. Handle the 2FA challenge (TOTP if Austin enrolled with an authenticator app; SMS would require a JP phone number bridge).
  4. Navigate to the transaction history page, set date range, download CSV.
  5. Drop the CSV onto the Synology NAS (/volume1/cloud/...) or commit directly to the renfroe-holdings repo via a deploy key.

Pros: fully automated; no human-in-the-loop after setup.

Cons:

  • The Mac is at the W3603 site, not Japan. TSB may geofence — verify by attempting login from the Mac before investing in automation.
  • 2FA via SMS is a hard blocker unless Austin can switch to authenticator-app TOTP.
  • TSB UI is in Japanese; selectors break on UI updates without warning. Maintenance cost.
  • Storing TSB credentials for automated access expands the attack surface meaningfully (this is a bank with a ¥780M mortgage on it; threat-model calibration warranted).

Time to wire up: ~1 day (Playwright script + selector tuning + 2FA flow + CSV-drop wiring + cron) IF geofence and 2FA cooperate. Significantly more if they don't.

Path 4 — Bank API (if TSB exposes one)

Open Banking is mandated in Japan but adoption is uneven, and TSB's specific API offering is not documented in the public sources I have access to as of 2026-05-09. Worth a 30-minute investigation:

  • Check tokyostarbank.co.jp for any "API" / "developer" / "オープン API" documentation.
  • Check FISC (Financial Information Standards Committee for Japan) registry of API-enabled banks.
  • If TSB is on the program, applying for API access likely takes weeks (corporate-account vetting) but yields the cleanest data feed.

Pros: if it exists, it's the canonical data source.

Cons: likely doesn't exist for retail/SMB tier; even if it does, registration overhead may be 1-3 months.

Path 5 — Skip transaction-level; reconstruct from advisor + statement summaries

If transaction-level granularity isn't critical, accept a coarser picture:

  • Mortgage payments are predictable from the amortization schedule (once we get the schedule).
  • Rental income, if we have a tenant lease, is also predictable.
  • Operating expenses can be approximated from the Japanese accountant's monthly trial balance.

Pros: zero technical work; uses what's already coming.

Cons: loses transaction-level resolution that's useful for FBAR detail, intercompany reconciliation, and audit defensibility.

  1. Now: add to todo/for-advisors.md (Japanese accountant) — request monthly TSB transaction export with each monthly deliverable. (Path 2.)
  2. Now: add to todo/for-austin.md — Austin to download the most recent 12-month TSB CSV and drop it on the Synology share. (Path 1, one-time backfill.)
  3. Once the first CSV arrives: build the parser + ingestion script (scripts/inboxes/tsb-csv-import.py) modeled on the existing JME packet ingestion pattern.
  4. After 3-6 months of monthly imports: if monthly cadence is reliable from Path 1+2, defer Path 3 indefinitely. If gaps emerge, evaluate Playwright (Path 3) or TSB API (Path 4).

Open questions

  • Does TSB online banking have a CSV export or only PDF? (Most Japanese banks support both; verify.)
  • What's TSB's date-range cap on transaction-history downloads? (Some Japanese banks cap at 90 or 180 days; if so, a one-time deeper backfill needs paper statements.)
  • Does Austin (or the GK officer-of-record) have credentials to log in directly, or is access only through the Japanese accountant?
  • Is the Japanese accountant's monthly deliverable already pulling TSB data, or do they pull from a different source (paper statements, GK's bookkeeping system)?
  • banking/tokyo-star-bank.md — current TSB context (account info, mortgage advance, basic facts).
  • accounting/mita-purchase-price-reconciliation.md — reconciled Mita purchase price (¥835,355,900 total economic cost).
  • accounting/mita-deep-dive.md — detailed acquisition history including the TSB ¥780M mortgage advance flow.
  • banking/monarch-coverage-map.md — confirms TSB is OUT of Monarch coverage.