Japan bank API and electronic payment agency route
Confidence Likely
Updated 2026-05-22
Review by 2026-11-22
Sources 6 Machine-translated Original (JA) #payments#bank-api#electronic-payment-agency#open-api#banking#fintech
On this page
Overview
Japan’s bank API / electronic payment agency route is the legal and operating bridge between banks and fintech apps that obtain account information, initiate account-linked instructions, or connect customer-facing services to deposit-account rails. It is not the same as being a bank, funds-transfer service provider, prepaid issuer, card acquirer, or wallet operator.
Use this page with payments domain, JapanFG legal / financial licenses, Japan account-to-account payment route, funds transfer vs prepaid boundary, BaaS Japan landscape, and Mercari Bank license stack.
Route Map
| Role | What it does | What it is not |
|---|---|---|
| Bank | Holds deposits, maintains accounts, and executes bank-account ledger movement. | Not merely an app front end. |
| Electronic payment agency operator | Connects to banks for account information / payment-instruction related services under the registered electronic payment agency route. | Not automatically a funds-transfer operator or prepaid issuer. |
| Funds-transfer operator | Moves funds under the Payment Services Act route. | Not automatically allowed to access bank APIs without the relevant bank / legal route. |
| Prepaid issuer | Issues stored-value instruments. | Not an account-information or payment-instruction service by itself. |
| BaaS / embedded finance app | Gives bank-like UX through a partner bank or licensed stack. | Not necessarily the licensed bank or electronic payment agency operator. |
| PSP / merchant gateway | Provides merchant acceptance and settlement services. | Not necessarily the account-information / bank API actor. |
Source Stack
| Source | What it proves |
|---|---|
| FSA license portal | Official entry point for electronic payment agency operators and related licensed / registered financial institutions. |
| FSA electronic payment agency list | Whether a named operator appears in the checked electronic payment agency registry. |
| FSA authorized electronic payment agency association list | Whether a self-regulatory / association route exists for the category. |
| JBA Open API model contract document | Practical bank / electronic payment agency contract issues and API-use pattern. |
| FAPI association links | Industry navigation surface for regulation and technical standard discussions. |
For a live company conclusion, check the exact legal name, registration number, as-of date, service scope, and bank API contract disclosure. Do not infer registration from a marketing page alone.
Product Boundary
| Product / flow | First question | Typical wiki route |
|---|---|---|
| Account aggregation / PFM | Is the app obtaining bank account information with user consent? | Electronic payment agency route plus bank API / contract disclosure. |
| Payment initiation from bank account | Who receives the user instruction and who executes the bank-account movement? | Electronic payment agency route, A2A payment route, and bank page. |
| Wallet top-up from bank account | Does value move into a wallet balance after account debit? | funds transfer vs prepaid boundary. |
| Merchant QR account-direct payment | Is the merchant payment Bank Pay / account-direct or wallet balance? | merchant account-direct acquiring. |
| Embedded bank account UX | Is the bank account held by the app company or partner bank? | BaaS Japan landscape. |
| Stablecoin / EPI handling | Is the instrument an electronic payment instrument or crypto asset? | ECISB and stablecoin regulation. |
JapanFG Relevance
- MUFG Bank, SMBC, Mizuho Bank, and Resona Bank matter because fintech account-linking depends on bank API / contract acceptance.
- SB Payment Service, Money Forward, and freee are examples of entities where account information, accounting, payment, and API routes can become strategically important.
- Merpay, PayPay, and au PAY be separated into wallet / funds-transfer / prepaid / account-direct / bank API layers rather than treated as one “payment app” category.
- Mercari Bank license stack is the clearest internal route for showing how a bank partner, app UX, and payment account can be split.
Control Questions
| Question | Public relevance |
|---|---|
| Is the operator registered as an electronic payment agency operator? | Registration is category-specific and must be checked in the FSA list. |
| Which bank APIs are used? | Bank API contracts and scopes vary by bank and service. |
| Is the service read-only or instruction-capable? | Information retrieval and payment / transfer instruction have different risk surfaces. |
| Who authenticates the user? | Bank authentication, app authentication, and consent management can be split. |
| Who bears unauthorized transaction risk? | User protection, bank liability, app liability, and fraud response depend on the legal / contract route. |
| Does value ever sit with the app? | If yes, funds-transfer / prepaid / wallet classification may be needed. |
| Is the merchant involved? | Merchant acceptance adds PSP / acquiring / settlement risk. |
Risks and Caveats
- Registration does not prove every API or payment function is active.
- A bank-linked UX can hide whether the app is only reading data, initiating instructions, moving funds, or holding wallet balance.
- Screen-scraping, tokenized API access, and contract-based API use are not interchangeable.
- Customer consent and authentication are operational controls, not just onboarding screens.
- Bank API outages can become payment, accounting, payroll, or reconciliation failures downstream.
- The electronic payment agency route is separate from electronic payment instrument / stablecoin routes.
Research Checklist
- Identify the legal entity, service name, and bank partners.
- Check the FSA electronic payment agency registry.
- Check whether the service is information-only, instruction-capable, or both.
- Check whether value is stored, remitted, prepaid, or only instructed.
- Check public API / bank partner disclosures and any user protection notices.
- Link the company page to legal / financial licenses and to the relevant payment or banking route.
Related
- INDEX
- account-to-account-payment-japan
- merchant-bank-pay-account-direct-acquiring
- funds-transfer-vs-prepaid-boundary
- funds-transfer-service-providers-japan-index
- baas-japan-landscape
- mercari-bank-license-stack
- INDEX
- mufg-bank
- sumitomo-mitsui-banking-corp
- mizuho-bank
- money-forward
- freee
- FinWiki index
Sources
- FSA: licensed / registered institutions portal.
- FSA: electronic payment agency operator registry.
- FSA: authorized electronic payment agency association list.
- Japanese Bankers Association: model API contract document.
- FAPI association: official link collection.
Discovery
Keep reading
Read next
- Japan BNPL and credit-purchase boundary BNPL in Japan is best treated as a checkout-credit boundary, not as a separate magic category. A product can look like "あと払い" while its legal / operating route touches installment sales, cre... payments/japan-bnpl-credit-purchase-boundary
- Japan BNPL / pay-later operator registry matrix Japan's BNPL / 後払い landscape is governed mainly by the 割賦販売法 (Installment Sales Act) through the 個別信用購入あっせん業者 (individual credit-purchase intermediary) registration line, with METI as the pr... payments/japan-bnpl-pay-later-operator-registry-matrix
- Japan card issuer, acquirer, and processor split Japan card payments is split into at least five roles: issuer, international / domestic brand, acquirer, card-number contract / merchant-contracting operator, and processor / PSP. A single g... payments/japan-card-issuer-acquirer-processor-split
Links here
- GMO Aozora Net Bank operating profile (GMO あおぞらネット銀行) This entry sits under banking index as the operating-profile companion to the entity anchor at GMO あおぞらネット銀行 entity anchor. Read it within the segment map at Japan net bank competition map... banking/gmo-aozora-net-bank
- Japan BaaS operating models Japan BaaS can be described by customer ownership, deposit-contract holder, UI controller, API provider, KYC / AML / fraud-monitoring responsibility, and license stack. A partner-branded app... banking/japan-baas-operating-models
- Japan net bank competition map Japan net-bank competition includes several public operating models: ecosystem retail banks, full-banking BaaS / white-label banks, SME / corporate API banks, securities / asset-formation ba... banking/japan-net-bank-competition-map
- Regional bank API and digital partnership route in Japan Regional-bank digital partnership in Japan is not just "a bank app." It is split into electronic payment agency API contracts, shared API platforms, bank-owned apps, accounting / treasury in... banking/regional-bank-api-digital-partnership-route
- Japan bank license and BaaS boundary Japan BaaS and embedded-banking records separate the licensed bank layer from the customer-interface layer. The controlling public category for deposit-taking is the Banking Act bank-license... financial-licenses/bank-license-and-baas-boundary