Japan bank API incident and fraud-control map

Overview

Bank API risk in Japan is not only a cybersecurity issue. It is a control chain across bank authentication, customer consent, electronic payment agency registration, API contracts, unauthorized withdrawal response, suspicious-transaction monitoring, reimbursement / complaint handling, and downstream reconciliation.

Use this page with Japan bank API route, Japan account-to-account payment route, merchant account-direct acquiring, PSP settlement risk, quick deposit methods, and JapanFG legal / financial licenses.

Incident Surface

Incident type	First question	Route to check
Account-information leak	Was the service read-only account aggregation or payment-instruction capable?	Electronic payment agency registration, bank API contract, consent log.
Unauthorized instruction	Who accepted the instruction and who executed bank-account movement?	Bank authentication, API scope, app login, transaction confirmation, customer notice.
Bank API outage	Is the failure at bank API, electronic payment agency, app, or downstream accounting / payroll route?	Bank status notice, API SLA / contract, reconciliation exceptions.
Account takeover	Was login compromised at bank, app, device, or shared credential layer?	Device / IP / login anomaly, step-up authentication, bank fraud desk.
Synthetic / mule account flow	Is the account being used as a pass-through for suspicious transactions?	FSA suspicious-transaction reference cases, bank AML monitoring.
Refund / reversal break	Did a payment instruction settle but merchant or accounting state fail?	A2A payment route, PSP reconciliation, merchant contract.

Control Stack

Layer	Control
Legal registration	Check whether the operator is in the FSA electronic payment agency registry.
Supervisory control	Check FSA supervisory guideline / security-enhancement materials for electronic payment agency risk points.
Bank contract	Confirm the bank / electronic payment agency API contract, service scope, and public disclosure.
Customer consent	Record consent timing, scope, purpose, and revocation route.
Strong authentication	Separate bank authentication, app authentication, and transaction confirmation.
API scope control	Minimize read / write permission, payment-initiation scope, and token lifetime.
Transaction monitoring	Watch test remittances, device / IP anomalies, unusual salary-like inflows, and mule-account patterns.
Reconciliation	Compare bank ledger, app state, merchant / accounting state, and user notification state.
Incident response	Preserve logs, freeze suspicious routes, notify bank / user / merchant, and route complaints.

Why The Boundary Matters

The same checkout or accounting UX can sit on different legal rails:

a bank-account information service routed through electronic payment agency;
an account-to-account transfer routed through Cotra / Bank Pay / J-Debit style rails;
a wallet balance routed through funds transfer or prepaid classification;
a merchant PSP settlement problem routed through PSP settlement risk;
an embedded-bank product routed through BaaS Japan landscape or Mercari Bank license stack.

Do not describe all of these as “bank API fraud.” The operational evidence and legal responsibility can differ sharply.

JapanFG Relevance

MUFG Bank, SMBC, Mizuho Bank, Resona Bank, and large regional banks matter because they operate the bank-account side of the API / authentication / complaint route.
Money Forward and freee are useful accounting / account-aggregation comparison anchors.
Merpay, PayPay, Rakuten Card, and au PAY need split analysis across bank API, wallet, prepaid, funds-transfer, and merchant rails.
SB Payment Service, GMO Payment Gateway, and Netstars matter when API failure flows into merchant checkout, settlement, or reconciliation.

Investigation Checklist

Identify the exact legal entity, user-facing service, bank partner, and API function.
Check FSA electronic payment agency registration and the bank’s public API / electronic payment agency disclosure.
Separate read-only account information from payment-instruction or transfer-related capability.
Reconstruct the timeline across app login, consent, bank authentication, instruction, bank ledger posting, merchant state, and notification.
Compare transaction monitoring signals against FSA suspicious-transaction reference cases.
Check whether the same incident also triggers funds-transfer, prepaid, PSP, merchant-acquiring, card, or AML reporting routes.
Record only public facts in FinWiki; keep incident-specific private data out of this public repository.

Sources

FSA: electronic payment agency registration guidance and registry.
FSA: electronic payment agency supervisory and security-enhancement materials.
FSA: reference cases on suspicious transactions.
FSA: public user-warning materials on illegal withdrawals / unknown transactions.
Japanese Bankers Association: model API contract document.
FISC / JEPPO: API and Bank Pay public control materials.
FAPI association: public regulatory / technical standard link collection.