リアルタイム決済とは？

1件あたり数億円規模の資金を動かす中央銀行のシステムと、スマートフォンの画面を数タップするだけで完了する個人間送金では、裏側で動くリアルタイム決済の技術アーキテクチャが根本から異なります。金融インフラとしての「マクロ決済」と、ECやFinTechが提供する「ミクロ決済」には、取引規模、接続プロトコル、リスク管理手法において明確な境界線が存在します。この2つのレイヤーにおける技術的・制度的背景の違いを整理することは、現代の決済インフラを理解する上で不可欠なアプローチです。

リアルタイム決済の定義と2つの潮流：金融インフラ（RTGS）と商取引（インスタントペイアウト）の技術的相違点

「リアルタイム決済」という言葉には、金融インフラとしての「マクロ決済」と、商取引や個人間送金における「ミクロ決済」の2つの異なるレイヤーが存在します。マクロ決済は中央銀行や銀行間ネットワークが担う、即時グロス決済（RTGS）などの基幹インフラを指します。一方、ミクロ決済はEC事業者やFinTech企業がエンドユーザーに向けて提供する「Stripe インスタントペイアウト」などの資金移動サービスや即時資金受け取りを指します。この2つのレイヤーは、取引規模、接続プロトコル、およびリスク管理手法において大きく異なります。ここでは、国家・銀行間インフラとしての仕組みに焦点を当て、その技術的・制度的背景を解説します。

日本銀行が主導する「即時グロス決済（RTGS）」と「時点ネット決済」のシステム的リスク比較

日本銀行が運営する「日銀ネット」などで採用されている「即時グロス決済 RTGS（Real-Time Gross Settlement）」は、1件ずつの取引を即時に、かつ他の取引と相殺せずに全額決済する手法です。これに対し、従来の「時点ネット決済（Deferred Net Settlement: DNS）」は、一定時間の取引を累積し、各銀行間の貸し借りを差し引いた差額（ネット残高）のみを特定の時点で一括して決済する仕組みです。

時点ネット決済では、日中に取引が成立していても、最終的な資金移動（ファイナリティの付与）は特定の決済時点まで保留されます。そのため、仮に特定の金融機関が決済時点の前に破綻した場合、その機関が関与するすべての決済が取り消されるか滞り、連鎖的に他の金融機関も決済不能に陥る「システム的リスク（連鎖的決済不能リスク）」が生じます。日本銀行は2001年1月に日銀ネットの当当座預金決済を原則RTGS化し、さらに2015年には新日銀ネットの稼働によって決済プロトコルを高度化しました。これにより、決済のファイナリティ（取り消し不能な確定決済）が即時に得られるようになり、システム的リスクが大幅に削減されました。

項目	即時グロス決済 RTGS	時点ネット決済 (DNS)
決済タイミング	取引発生ごとに即時	特定の決済時点（一括バッチ）
決済金額の計算	個別の総額（グロス）	差額（ネット）の相殺
システム的リスク	極めて低い（即時にファイナリティ確定）	高い（連鎖的決済不能のリスクあり）
流動性の必要量	決済ごとに資金が必要なため高い	相殺されるため比較的少額で済む

RTGSは高い決済流動性を必要とするため、日本銀行は日中一時的に無利息で資金を供給する「日中当座貸越」制度を提供しています。この制度により金融機関の流動性不足を補完し、リアルタイム決済のメリットである金融システム全体の安全性維持が担保されています。

全銀システム稼働時間拡大（モアタイムシステム）と民間決済サービスの接続アーキテクチャ

日本国内の個人・企業間におけるリアルタイム送金の仕組みの中核を担うのが、全国銀行資金決済ネットワーク（全銀ネット）が運営する「全銀システム」です。従来の全銀システム（コアタイムシステム）は、平日の8:30から15:30までの稼働に制限されていました。これに対し、2018年10月に稼働を開始した「モアタイムシステム」により、24時間365日の「全銀システム リアルタイム決済」が実現しました。

モアタイムシステムは、従来のメインフレームを中心としたコアタイムシステムとは異なる、並行分散型のサブシステムとして設計されています。その主な接続構造は以下の通りです。

• 2系統の並行稼働： 昼間のコアタイム時間帯は既存システムが処理を行い、夜間・休日（モアタイム）はモアタイムシステムが処理を引き継ぎます。これにより、既存の重厚な勘定系システムに過度なリアルタイム処理負荷をかけずに24時間化を達成しています。
• RC（Relay Computer）による仲介： 各金融機関の勘定系システムは直接全銀システムと通信するのではなく、RC（中継コンピュータ）を介して非同期でメッセージを送受信します。これにより、特定の銀行が夜間メンテナンスで一時停止している場合でも、決済電文を一時的にバッファリングして処理の切断を防ぐ設計が採用されています。
• API接続による民間サービスの統合： フィンテック企業などの民間決済事業者は、各銀行が公開するオープンAPI（更新系API）を経由してこのインフラにアクセスします。ユーザーがスマートフォンの決済アプリで送金を実行すると、APIを通じて銀行の勘定系システムに命令が伝わり、全銀システムを通じて即時に振込が実行されます。

全銀システムにおける決済処理性能は、モアタイムシステムの導入により強化され、大量のトランザクションを並行して受信する能力を維持しています。民間決済サービスとのAPI連携において、各銀行に求められる中継レスポンスタイムは平均2秒以内とされており、この高速な通信処理によって、モバイルアプリ上での遅延のないリアルタイム送金の仕組みが成立しています。

ビジネスにリアルタイム決済を導入する意思決定：キャッシュフロー改善効果とシステム要件の対照表

事業者にとって決済手段のリアルタイム化は、単なる利便性の向上に留まらず、財務構造の効率化を直接的に推進する手段です。従来の週次や月次のバッチ処理による売上回収モデルでは、売上が発生してから実際に預金口座へ入金されるまでに15日から45日程度のタイムラグが発生し、これが運転資金の固定化という形で事業の成長速度を抑制していました。この回収期間を限りなくゼロに近づけることは、キャッシュ効率の極大化に直結します。

売上金回収を「数分」に短縮するStripeインスタントペイアウトの仕組みと資金効率シミュレーション

「Stripe インスタントペイアウト」は、提携金融機関の即時決済ネットワークやデビットカードの送金インフラを利用し、売上発生から最短数分で指定の銀行口座へ資金を移動させるリアルタイム送金の仕組みです。日本国内においては、全銀システムによるリアルタイム決済（モアタイムシステム）とのシームレスな連携により、24時間365日の即時着金を実現しています。このシステムは、従来の数日〜数週間を要する銀行振込や、カード決済の標準的な入金サイクル（月1回または2回）を置き換えるものです。

このリアルタイム決済のメリットを定量的に評価するため、以下の条件を持つオンラインサービス事業者をモデルに、資金効率のシミュレーションを行います。

• 事業者モデル： 月商3,000万円（1日平均100万円の売上）、売上原価率50%（仕入れ・外注費が月1,500万円、1日平均50万円）
• 従来の決済環境： 月2回締め・15日後払い（平均売掛金回収期間：22.5日）
• 改善後の決済環境： Stripe インスタントペイアウトを導入（回収期間：0日、数分で着金）

従来の環境では、仕入債務の支払期間を30日とした場合でも、タイミングによっては仕入れ資金や広告費が先行するため、キャッシュアウトを補填するために手元に約750万円の運転資金（キャッシュバッファ）を常時維持する必要がありました。しかし、Stripe インスタントペイアウトの導入により売上金が即日口座に入金されることで、日々の広告費や仕入れ費用を当日の売上金から直接相殺可能になります。

この結果、必要となる運転資金は750万円からほぼ0円へと圧縮され、キャッシュ・コンバージョン・サイクル（CCC）の短縮によって浮いた資金を、新規顧客獲得のための広告投資や在庫確保に即座に再投資できます。Stripeが設定する1%前後のインスタントペイアウト手数料を差し引いても、資金回転率の向上に伴う売上成長が手数料コストを上回ることが、実財務データを用いた試算により確認されています。

P2P・P2B・B2Bにおけるユーザー体験（UX）向上とチャージバック（不正利用）リスクのトレードオフ

決済の即時化は、利用者にとって高い利便性を提供する一方で、事業者側には「取り消し不能な資金移動」に伴う決済リスクの管理が求められます。特に中央銀行の即時グロス決済（RTGS）と同様に、一度処理が確定した決済は即時にファイナリティを得るため、従来のバッチ処理のように「夜間のバッチ処理前に不正を検知して取引を止める」という猶予がありません。

以下に、P2P、P2B、B2Bの各領域におけるUX上のメリットと、チャージバックや即時返金処理にかかる運用リスクとのトレードオフ、およびそれを緩和するためのシステム要件を整理します。

セグメント	UX向上効果	運用リスク・課題	緩和策・システム要件
P2P（個人間）	割り勘や個人間売買において、数秒で相手の口座に資金が届き、即時に確認・利用可能。	送金ミス（誤送金）やフィッシング詐欺による不正送金。即時着金するため組戻し手続きが極めて困難。	送金前の宛先名義自動照会（ネームバリュー機能など）の義務化、AIによる不審取引のリアルタイム検知。
P2B（個人対ビジネス）	デジタルコンテンツや購入チケットの即時発行。購入後すぐにサービスが受けられる。	クレジットカード等の不正利用によるチャージバック発生時の、サービス提供済みによる回収不能。	3Dセキュア2.0（EMV 3-D Secure）の必須化、決済実行前の不正検知API（Sift等）によるスコアリング。
B2B（企業間取引）	納品と同時に決済が完了し、与信管理の負担を削減。下請代金支払の迅速化。	請求書情報の改ざん（ビジネスメール詐欺）による巨額の誤送金。一度送金されると即時回収が不能。	送金元・送金先における2要素認証の徹底、EDI（電子データ交換）と連動した自動照合システムの構築。

P2Bにおけるチャージバック対策の例として、EMV 3-D Secureを用いた認証プロセスが挙げられます。これを導入することで、カード発行会社が不正利用リスクを判定し、事業者はチャージバック発生時の債務保証（ライアビリティシフト）を受けることが可能になります。リアルタイム決済のメリットを最大化するためには、決済速度の向上と同調する形で、こうしたトランザクションの正当性を1秒未満で検証するリアルタイム・リスクスコアリングシステムの導入が前提条件となります。

海外と日本におけるリアルタイム決済（RTP）インフラの現在地：FedNow・ACHと日本市場の技術比較

海外におけるリアルタイム決済（RTP）インフラは、中央銀行主導の即時グロス決済（RTGS）インフラの整備と、国際標準規格「ISO 20022」への移行によって急速に高度化しています。

米国では、従来のバッチ処理を基本とするACH（自動決済機関）に対し、2023年7月に連邦準備制度理事会（FRB）が運用を開始した即時決済インフラ「FedNow」の導入が進んでいます。FRBの公表データによると、2024年末時点で導入金融機関は1,000行を超え、2026年現在では米国内の全預金取扱機関の約半数がFedNowに対応しています。従来の同日ACH（Same-Day ACH）が1件あたり最大100万ドルの上限があり、かつバッチ処理によるタイムラグが存在したのに対し、FedNowは24時間365日、即時での資金移動を可能にするリアルタイム送金の仕組みを提供しています。

欧州市場では、単一ユーロ決済圏（SEPA）における「SEPA Instant Credit Transfer（SEPA Inst）」が先行しています。欧州議会が2024年2月に可決した「即時決済規則（Instant Payments Regulation）」により、ユーロ圏のすべての決済サービスプロバイダー（PSP）に対して即時決済の提供が義務付けられました。これにより、2026年現在、ユーロ圏内におけるSEPA送金全体に占める即時決済の比率は80%を超えています。

これら欧米のRTPインフラを技術的に支えているのが、金融通信メッセージの国際規格「ISO 20022」です。従来のレガシーなフォーマット（米国のFedwireで使われていたProprietary形式や、SWIFTのMTメッセージ）と比較して、ISO 20022はXMLベースの構造化された豊富なデータ（エンドツーエンドの送金目的コードや詳細な請求書情報など）を内包できるため、AML（資金洗浄防止）フィルタリングの誤検知率を低下させ、ストレート・スルー・プロセッシング（STP）率を99%以上に高める効果を発揮しています。

インフラ名	対象地域	決済方式	標準データ規格
FedNow	米国	即時グロス決済 RTGS	ISO 20022
Same-Day ACH	米国	時点ネット決済（バッチ）	Nachat形式
SEPA Inst	欧州（ユーロ圏）	即時グロス決済 RTGS	ISO 20022

国内リアルタイム送金市場のセグメント別分析とプレイヤーマップ（P2P、B2B決済のデジタル化）

日本国内におけるリアルタイム決済の市場規模は、金融インフラの近代化と決済サービスプロバイダーの多様化に伴い、高い成長を維持しています。2024年から2030年にかけての国内の即時・リアルタイム決済取扱高の年平均成長率（CAGR）は、約12.5%と予測されています。この成長を牽引する主なセグメントは、個人間送金（P2P）と企業間決済（B2B）のデジタル化です。

日本の金融インフラの基盤である全銀システム（全国銀行データ通信システム）は、2018年に稼働した「モアタイムシステム」により、24時間365日の全銀システムによるリアルタイム決済をすでに実現しています。しかし、従来の銀行口座主動の仕組みから、近年はAPIを活用したFinTechプレイヤーやグローバルな決済プラットフォーマーとの接続により、ユースケースが細分化しています。

P2P（個人間送金）セグメントでは、「PayPay」や「LINE Pay」といったコード決済事業者のアカウント残高を用いた送金や、銀行間リアルタイム送金アプリ「ことら送金」が市場を牽引しています。ことら送金は1回あたり10万円以下の送金をターゲットとし、モアタイムシステムをバックエンドに利用することで、低コストかつ即時性の高い資金移動を実現しています。

B2BおよびB2C（企業から個人）の送金セグメントでは、特に給与のデジタル払いやEC事業者への即時入金ニーズが急増しています。例えば、加盟店向けの即時出金サービスである「Stripe インスタントペイアウト」は、デビットカードのネットワーク（Visa Direct等）を活用することで、全銀システムを経由しないリアルタイム送金の仕組みを日本国内でも提供しています。これにより、EC事業者は売り上げ確定後、数分以内に資金を手元に回収でき、運転資金の効率化というリアルタイム決済のメリットを直接的に享受しています。

セグメント	主なユースケース	活用される主要インフラ・サービス	決済完了時間
P2P（個人間）	割り勘、個人間送金	ことら送金、コード決済アプリ	即時（数秒）
B2C（企業から個人）	給与即時払い、フリーランス報酬	モアタイムシステム、資金移動業者API	即時（数秒〜数分）
B2B（企業間）	売掛金回収、加盟店向け即時出金	Stripe インスタントペイアウト、全銀EDIシステム	即時（数秒〜数分）

このように、国内のリアルタイム決済市場は、全銀システムを核とした伝統的な銀行インフラと、海外の先進テクノロジーをベースにしたFinTechプラットフォームが共存・連携する構造へとシフトしています。これらのインフラのAPI連携状況や手数料構造の推移を監視することは、次世代の決済サービス設計における投資判断基準となります。

EC事業者・FinTech開発者のためのリアルタイム決済API実装フローと障害設計ガイド

決済API（Webhook含む）を用いた残高確認から即時送金実行までのWebシーケンス

ユーザーが資金の即時移動をトリガーした際、システムは一連の同同期・非同期的処理を遅延なく実行する必要があります。日本国内における24時間365日の稼働を支える全銀システムによるリアルタイム決済（モアタイムシステム）への接続や、Stripe インスタントペイアウトなどの決済プロバイダーを利用する場合、以下のWebシーケンスに沿ってリアルタイム送金の仕組みを構築します。

• ステップ1：クライアントから自社バックエンドへの送金要求
  ユーザーが送金ボタンを押下した際、クライアントはクライアント側で生成した一意の取引IDをヘッダーに含めてPOSTリクエストを送信します。
• ステップ2：自社台帳での一時引き当て（ローカル・トランザクション）
  二重送金を防ぐため、自社データベース上で該当ユーザーの残高が十分であるかを確認し、送金対象額を「処理中（Pending）」としてロックします。この一過性の状態管理には、PostgreSQLの「SELECT FOR UPDATE」などを用いた行ロックが有効です。
• ステップ3：決済ゲートウェイ／銀行APIへのリクエスト送信（同期的呼び出し）
  決済ゲートウェイまたは即時グロス決済（RTGS）に対応した接続APIに対し、送金指示を同期的に発行します。
• ステップ4：暫定レスポンスの受信とクライアントへの応答
  外部APIから「受理（Accepted/Processing）」のステータスを受け取った時点で、バックエンドは一度クライアントに処理中である旨を返却し、画面のスピナーを解除します。
• ステップ5：外部システムからの非同期Webhook受信
  銀行や決済プロバイダー側での決済処理が完了すると、事前に登録したエンドポイントへWebhookが通知されます。
• ステップ6：残高の確定（コミット）と即時反映
  Webhookのペイロード（署名検証済み）を検証後、データベース上の残高ステータスを「処理中」から「完了（Completed）」へ更新し、WebSocketやServer-Sent Events（SSE）を用いてユーザー画面へ即時反映します。

処理フェーズ	送信元	送信先	トランザクション状態
送金リクエスト	クライアント	自社サーバー	Pending（一時ロック）
外部決済実行	自社サーバー	決済プロバイダーAPI	Processing（外部処理中）
非同期結果通知	決済プロバイダー	自社Webhook API	Processing（署名検証）
残高の最終確定	自社サーバー	自社データベース	Completed（コミット完了）

このように処理を同期的な受付と非同期の確定処理に分離することにより、全銀システムによるリアルタイム決済のピークタイムにおけるネットワーク遅延が発生した場合でも、ユーザーを画面の前で長時間待たせることなく、スムーズなユーザー体験を提供できます。

二重決済・タイムアウト・通信障害を防止する「冪等性キー（Idempotency Keys）」の実践的な設計

ネットワーク瞬断やAPIの応答遅延時、ユーザーが送金ボタンを連打したり、クライアントシステムが自動リトライを試みたりすることで発生する「二重決済（多重送金）」は、金融システムにおいて許容されません。資金が即時に移動するリアルタイム決済のメリットを安全に享受するためには、分散システムにおける「強整合性」を担保する冪等性（Idempotency）の設計が必須です。

具体的な設計手法として、クライアント側で生成した「UUID v4」を「Idempotency-Key」としてリクエストヘッダーに付与させます。自社バックエンドおよび接続先API（Stripeなど）は、このキーをキー・バリューストア（Redis等）に保存し、一定時間内の重複リクエストを検知・排除します。

リクエスト受信時の状況	Redis内のキー状態	サーバー側の処理フロー	応答ステータスコード
新規リクエスト	存在しない（未処理）	キーを「処理中」として登録（TTLを設定）し、実処理を実行する。	200 OK / 201 Created
重複リクエスト（処理中）	「処理中（Active）」	前回の処理が継続中のため、要求を破棄して待機を促す。	409 Conflict
重複リクエスト（完了済）	「完了（Saved Response）」	実処理をスキップし、Redisに保存されている前回のレスポンスをそのまま返却する。	200 OK（キャッシュ返却）

この設計において、Redisに格納するデータの生存期間（TTL：Time To Live）は、決済の性質に合わせて設定する必要があります。一般的に、突発的なリトライに対応するためには24時間のTTLを設定することが推奨されます。RedisのSETコマンドにおいて「NX（Not Exist）」オプションと「PX（ミリ秒指定の有効期限）」を併用することで、競合状態（レースコンディション）を完全に排除したアトミックなキー確保が実現可能です。例えば、Node.js環境であれば、Redisクライアントを用いてアトミックな書き込み・取得操作を1つのクエリで実行します。

また、決済プロバイダーとの通信でタイムアウト（HTTP 504等）が発生した場合のリトライポリシーには、必ず「指数バックオフ（Exponential Backoff）」と「ゆらぎ（Jitter）」を組み込みます。瞬時の再試行を避け、リトライ間隔を「1秒、2秒、4秒、8秒 ＋ 乱数」のように段階的に広げることで、相手方サーバーの過負荷によるシステム全停止を回避します。接続先の障害が長引く場合は、最大リトライ回数（一般的に3〜5回）に達した時点で自動リトライを打ち切り、トランザクションを「要手動調査（Suspended）」ステータスへ移行させて、サーキットブレーカー（Circuit Breaker）パターンにより以降のリクエストを一時的に遮断するロジックを実装します。

自社ビジネスに最適なリアルタイム決済インフラを選定するための要件定義チェックシート

リアルタイム決済の導入は、キャッシュフローの劇的な改善をもたらす一方で、インフラの選択によって初期開発コストや運用手数料、処理遅延（レイテンシ）が大きく異なります。自社のビジネスモデル（EC、ギグワーカー向け即時支払、B2B決済など）に合致した最適なインフラを選択するためには、コスト、速度、開発難易度の3軸から技術・コスト評価を行う必要があります。

コスト・処理速度・開発難易度で分類する「決済ソリューション選定マトリクス」

リアルタイム決済のインフラは、大きく分けて、Stripeなどの「サードパーティ決済サービス」と、銀行が提供する「直接的銀行API（全銀システムによるリアルタイム決済に接続するオープンAPIなど）」の2種類に分類されます。それぞれの特徴を評価したマトリクスは以下の通りです。

評価項目	サードパーティ決済サービス（例: Stripe）	直接的銀行API接続
処理速度	数秒〜数分（API経由で数秒以内に完了）	即時（即時グロス決済 RTGSやモアタイムシステム経由）
導入コスト	初期費用0円、決済手数料（数%＋数十円/件）	初期数百万〜（個別接続・中継システム開発費）
開発・保守難易度	低い（SDK/APIが完備され数日から数週間で実装可能）	高い（銀行固有の仕様調整やセキュリティ基準への準拠）
主なユースケース	EC、C2C、ギグワーカーへの報酬即時支払	大企業のB2B決済、高額商品の即時取引

例えば、ギグワーカー向けに24時間365日の報酬即時払いを提供するマッチングプラットフォームの場合、Stripe インスタントペイアウトを活用することで、開発リソースを最小限に抑えつつ最短数秒での資金移動が実現可能です。実際に、Stripeのインスタントペイアウトは、手数料率（通常1%前後、最低額設定あり）を支払うことで、デビットカードのネットワークを経由して登録済みの口座へリアルタイム送金を行う仕組みを採用しています。一方で、月間の送金件数が数万件を超え、一件あたりの送金単価が数十万円に達するB2Bの仕入れ決済システムなどの場合は、トランザクションごとのパーセンテージ手数料が経営を圧迫するため、全銀システムによるリアルタイム決済（モアタイムシステム）に直接的銀行APIで接続する方が、中長期的なランニングコストを大幅に抑制できます。全銀システムによるリアルタイム決済は、1件あたり数十円の固定手数料で即時送金が可能なため、送金総額が大きいビジネスモデルにおいて高い投資対効果（ROI）を発揮します。

導入プロジェクト開始時に財務部門とシステム開発部門が合意すべき3つのKPI項目

リアルタイム決済を導入する際、ビジネス側の要件（財務部門）とシステム側の要件（開発部門）の不一致により、プロジェクトが長期化するケースが多発します。この対立を防ぎ、スムーズな意思決定を行うために、キックオフ時点で以下の3つのKPI項目を定義・合意する必要があります。

• 1. トランザクションあたりの許容限界コスト（CoT: Cost of Transaction）

  財務部門が許容できる1決済あたりの総手数料（定額および定率）の限界値を設定します。月間トランザクション件数5万件、平均決済単価5,000円のECサイトの場合、サードパーティ決済を利用すると決済手数料（例：3.6%）で1件あたり180円のコストが発生します。これを直接的銀行API接続に切り替えることで、初期開発費に500万円投資しても、1件あたりのトランザクション手数料を10円に抑制できれば、約3万件（約7ヶ月）の取引で初期投資を回収できる計算になります。この損益分岐点を明確にし、コスト削減効果というリアルタイム決済のメリットを財務部門に提示して合意を形成します。

• 2. 決済処理の許容遅延時間（エンドツーエンド・レイテンシ）

  システム開発部門が保証すべき、ユーザーが送金ボタンを押してから口座残高に反映されるまでの時間（秒単位または分単位）を規定します。例えば、即時グロス決済（RTGS）を基盤とするリアルタイム送金の仕組みを自社で構築する場合、24時間365日いつでも秒単位で資金移動を確定させることができます。特に、全銀システムに直結するAPIの場合、夜間・休日のモアタイム時間帯における処理速度の変動を考慮し、サービス品質保証（SLA）として「99.9%のトランザクションを3秒以内に完了する」といった具体的な数値を開発部門と合意しておくことが必要です。

• 3. エラー処理および自動組戻（リバート）の完了率と所要時間

  振込先口座番号の入力誤りや取引限度額超過など、決済エラーが発生した際の資金回収・返金処理のKPIです。リアルタイム決済では、資金が即時に移動するため、従来のバッチ処理（時点ネット決済など）のように「当日中なら当日キャンセル（組み戻し）が容易」というわけにはいきません。エラー検知からユーザーへの自動返金処理（リバート）を「5分以内に95%以上完了する」というKPIを開発部門がシステム設計（冪等性の確保やリトライ処理）に組み込むことで、財務部門の監査や問い合わせ対応にかかる手動オペレーションコストを低減できます。

よくある質問（FAQ）