執筆者:Awang、Web3弁護士
デジタル決済は主流になりつつあるが、決済システムはまだ主流とは言えない。
これは、元Visa幹部でBeamの創業者であるダン・モティス氏の見解です。Visaの取引は世界中のどの加盟店でも承認されますが、舞台裏での決済は依然としてSWIFTで行われています。つまり、大量の取引を集約し、国境を越えた電信送金で資金を移動し、現地の規制、祝日、複数の仲介銀行を経由し、加盟店は支払いを受け取るまで待たなければなりません。これはVisaだけの問題ではなく、業界全体に共通する構造的な欠陥です。そして、この欠陥が最も集中しているのはPSP(個人サポートサービス)です。
本稿では、決済サービスプロバイダー(PSP)に焦点を当てる。PSPは、単純な決済回収ツールから、資金の流れ、決済、会計を管理する中核的なインフラストラクチャ層へと進化を遂げてきた。もともとは、単一トラックシステム、直線的な取引処理、高度に統合されたインフラストラクチャといった、よりシンプルな時代のために設計されたものだった。
現代の決済環境において、「決済」はもはや単一の取引ではなく、複数の参加者と決済経路にまたがる一連の状態遷移を指します。今日では、決済には、消費者向けアプリケーション、決済サービスプロバイダー(PSP)、不正防止/本人確認サービスプロバイダー、保管銀行、1つ以上の決済経路、そして企業の内部会計システムなどが関与する可能性があります。
企業は、銀行カード、ACH、電信送金、RTP、FedNow、そしてますます普及が進むステーブルコイン決済など、様々な決済手段を同時にサポートする必要があります。それぞれの決済手段には、決済時間、障害発生モード、データ形式、運用要件が異なります。
この記事は、Modern Treasuryのガイドをまとめたもので、決済サービスプロバイダー(PSP)がどのように進化してきたか、その基盤となるアーキテクチャが現代の決済システムにどのように適応する必要があるか、そして決済製品を開発するチームが次のPSPを選択する際にどのような戦略を採用すべきかを解説します。
中核的な判断
01|デジタル決済は主流になりつつありますが、決済システムはまだ主流になっていません。Visaを使えば世界中のあらゆる加盟店で取引を承認できますが、決済システムは依然としてSWIFT上で稼働しています。インターフェースは解決済みですが、根本的な仕組みは未解決のままです。
02 | PSPは決済を実行しますが、資金の流れについては説明しません。Stripeはその時点で何が起こったかを教えてくれますが、現在の資金の真の状態は教えてくれません。実行レイヤーと記録レイヤーは別物です。
03 | 各決済トラックは独立したオペレーティングシステムであり、同じモデルの派生版ではありません。ACHは取り消し可能ですが、RTPは取り消しできません。カードネットワークは異議申し立てが可能ですが、ステーブルコインはオンチェーンで確定されます。PSPの抽象化レイヤーはこれらの違いを隠蔽しますが、問題が発生するまではその状態が続きます。
04 | リアルタイム決済ではバッファが不要になるため、管理を上流工程に移す必要があります。従来の決済サービスプロバイダー(PSP)のリスク管理、承認、および照合ロジックはすべて、「エラーを修正する時間がある」ことを前提としています。RTPとFedNowはこの前提を排除します。資金移動後ではなく、資金移動前に意思決定を行う必要があります。
05 | ステーブルコインは決済手段であり、新しい支払い方法ではありません。決済インターフェースの問題を解決するのではなく、「会計処理完了」から「実際の資金到着」までの遅延を解消します。最も実用的な実装方法は、サンドイッチ構造です。つまり、法定通貨を入金し、オンチェーンで流通させ、再び法定通貨を払い出すという流れで、両端のユーザーはステーブルコインを理解する必要がありません。
06 | 送金中の資金が収益を生み出すことが可能になる。これは従来のシステムではほとんど見られない現象だ。国境を越えた決済では、資金は決済完了まで24時間から72時間拘束され、収益は発生せず、運転資金が滞留してしまう。ステーブルコインは、「送金中の資金」が価値を生み出すことを初めて可能にした。
07 | 決済業務における最大の失敗は、「このお金はどこへ行ったのか?」という単純な質問に答えられないことです。照合、異常処理、流動性管理といった問題は、決済開始時ではなく、決済後に発生します。統一された調整レイヤーがなければ、各サービスプロバイダーは自社の情報しか提供できません。
08 | 真の戦略的リスクは、ステーブルコインを使うかどうかではありません。競合他社が決済コストと資本効率を再構築するためにステーブルコインを使用している一方で、あなたが完璧な参入機会を待っているという点です。
I. PSPの歴史的進化

過去20年間で、PSPの役割は根本的な変化を遂げた。
電子商取引の黎明期において、決済サービスプロバイダー(PSP)は主に決済ゲートウェイとして機能していた。その役割はシンプルかつ明確で、加盟店をカードネットワークやアクワイアリング銀行に接続し、取引の承認と決済を可能にすることだった。
これらのPSPシステムは、非常に特殊な世界向けに設計されています。支払いは主にカードベースで行われ、単一の加盟店アカウントを経由して、承認から決済まで直線的なライフサイクルで処理されます。PSPは、このモデル内で取引を効率的に処理するように最適化されています。
2010年代に入ると、マーケットプレイス、SaaSプラットフォーム、フィンテック製品などが、決済機能を自社のサービスに直接組み込むようになった。プラットフォーム側は、ユーザーのオンボーディング、複数の関係者間での決済分割、資金移動の管理といった業務を担う必要があった。決済サービスプロバイダー(PSP)もこれに合わせて事業を拡大し、加盟店のオンボーディング、決済インフラ、不正防止ツールなどを導入した。
しかし、PSPの機能は絶えず拡大しているにもかかわらず、その基盤となるアーキテクチャは、直線的な決済処理を目的としたモデルに根ざしており、サービスプロバイダーやトラックをまたいだ複雑な多段階の資金移動を調整するよりも、主に取引処理に最適化されている。
2020年代初頭までに、企業は複数のトラック、地域、シナリオにわたって事業を展開するようになった。従来の決済サービスプロバイダー(PSP)は、引き続き多数のコンポーネントを統合し、企業が単一のプラットフォームでやり取りできるようにしていた。しかし、決済プロセスが複雑化するにつれ、単一の決済プロセスには、本人確認、リスク評価、資金調達の決定、トラックの実行、内部追跡など、複数のステップが含まれるようになった。
この変化により、PSPの役割は「コネクター」から「コーディネーター」へと変わったが、そのアーキテクチャは同じペースで進化しなかった。
その結果、決済サービスプロバイダー(PSP)は依然として資金の送金責任を負うものの、取引決済のライフサイクル全体を網羅する、より複雑な環境の中で業務を行うことになる。
II. 最新のPSP決済技術スタック
PSPの限界を理解するには、まずそれが存在するより広範な決済環境を理解する必要がある。

2.1 PSPテクノロジースタック
現代の決済環境は、単一のプラットフォームやサービスプロバイダーではなく、資金の移動、決済、会計処理をサポートするために連携して機能する、階層化されたインフラストラクチャコンポーネントの集合体である。
アプリケーション層:決済開始型のeコマースプラットフォーム、マーケットプレイス、フィンテックアプリ、および決済機能を組み込んだSaaS製品。
PSPレイヤーは、カードネットワークへのトランザクションのルーティング、銀行振込の開始、決済トラックへの接続など、決済指示の実行を担当します。ほとんどの場合、これらの複雑な処理はPSPのインターフェースの背後で抽象化されているため、ユーザーは複数のサービスプロバイダーと直接やり取りするのではなく、単一のシステムと対話することができます。
コンプライアンス層:現代の決済プロセスは、本人確認サービスプロバイダー、不正検出ツール、およびコンプライアンスインフラストラクチャにも依存しており、これらが決済の実行を許可するかどうかを決定します。
銀行レベルでは、カストディアン銀行が資金を保管し、規制対象の口座を提供し、ACH、電信送金、RTP、FedNowなどの決済ネットワークへのアクセスをサポートします。
内部照合レイヤー:企業が残高を追跡し、取引状況を示し、財務活動の一貫した記録を維持するために使用するシステム。
これらの各層は資金の流れにおいてそれぞれ役割を果たしますが、支払いが開始された後に実際に何が起こるのかを完全に把握できる層は存在しません。まさにこの理由から、内部照合層が不可欠となるのです。
2.2 同期と非同期
従来のPSPには根本的な設計上の欠陥があった。それは、送金することだけを重視し、その後に何が起こるかは気にしていなかったことだ。
問題は、「発送後」こそが、支払いプロセスの中で最も複雑な部分であるということだ。
PSPのAPIインターフェースのロジックは同期型です。コマンドを送信すると、結果が返されます。しかし、実際の資金の流れは非同期型です。決済は後から完了し、エラーは遅れて顕在化し、払い戻しや取消はいつでも取り消すことができます。この不一致が、永続的な情報ブラックホールを生み出しています。
ブラックホールの具体的な現れは、その状態の断片化である。

いかなる時点においても、この資金の真の状態を正確に把握することはできません。
マーケットプレイスプラットフォームにおける販売者からの出金を例にとると、そのプロセス全体は、資格確認→リスク管理とコンプライアンス→資金確認→指示の発行→取引の実行→確認の受領→取引後の決済→台帳の更新という長い連鎖です。PSPは中間段階の一部のみをカバーしており、それ以前の意思決定やその後の照合はPSPの責任範囲外です。支払いが失敗したり返金されたりした場合、単一のシステムでは完全な回答を提供することはできません。
内部調整レイヤーの重要な点は、決済処理において決済サービスプロバイダー(PSP)に取って代わるものではなく、むしろチェーン全体の上に統一された監視レイヤーを構築することです。異なるサービスプロバイダーから異なるタイミングと形式で送られてくる非同期イベントを、企業内で単一の信頼できる状態に継続的に変換します。資金がどれだけ多くの仲介者を経由しようとも、最も根本的な問いである「この資金は今どこにあるのか?」に答えられる場所は常に一つだけ存在するのです。
III.従来の決済サービスプロバイダー(PSP)における支払い制限
従来の決済サービスプロバイダー(PSP)の抽象化レイヤーは、銀行カード決済(承認、キャプチャ、決済)を中心に構築されており、そのライフサイクルは予測可能です。例外(紛争やチャージバックなど)は存在するものの、全体的な構造は予測可能で、十分に理解されています。このモデルは、PSPの設計方法に影響を与えています。
新たな決済方法の登場に伴い、PSPはより多くの決済手段への対応を拡大するだろうが、これらの決済手段は銀行カードとは異なる挙動を示し、同じ前提には当てはまらない。
- ACH送金:遅延が発生する可能性があり、支払い開始後数日経ってからキャンセルされる可能性もある。
- 電信送金:決済は迅速ですが、通常は手作業による処理が必要で、費用も高くなります。
- RTPやFedNowといったリアルタイム決済ネットワークは資金の即時移動を可能にするが、取引は一度完了すると通常は取り消し不可能である。
- ステーブルコインの送金は、全く異なるインフラストラクチャ上で動作し、セキュリティメカニズムや運用上の考慮事項も異なります。
例えば、米国企業がフィリピンのサプライヤーに支払う場合を考えてみましょう。
- ACHをご利用の場合、資金はT+2で到着しますが、フィリピンの銀行はACHを直接受け付けていません。資金は途中で現地の送金チャネルを経由して送金されるため、実際の到着時間はT+4となる場合があります。この期間中、口座情報の不一致などにより、注文がいつでもキャンセルされる可能性があります。
- 電信送金は迅速ですが、午後3時の送金締め切り時間までに送金手続きを完了する必要があります。締め切り時間が祝日の場合は、送金が遅れる可能性があります。SWIFT送金の手数料は25ドルから45ドルで、受取銀行が仲介銀行手数料を差し引く場合もあるため、最終的に受け取る金額は送金金額と一致しない場合があります。
- ステーブルコインサンドイッチ方式を用いることで、USDCは米国の口座から発行され、数秒でオンチェーン上で承認された後、フィリピンのパートナーによってペソに変換され、現地の口座に入金されます。このプロセス全体は1時間以内に完了し、手数料は送金額の1%未満です。
支払い方法は3種類あり、金額は同じでも、決済時間は96時間も異なり、手数料も数十ドルも差があり、追跡方法も全く異なっていました。これは製品体験の違いではなく、3つのオペレーティングシステムの違いでした。PSPの抽象化レイヤーではこれらの違いを隠すことはできず、開発者と運用チームが理解できるように、それらを上位の担当者に押し付けるしかありませんでした。
これらは同じ支払いモデルのバリエーションではなく、根本的に異なる運用モデルである。
PSPの従来のアプローチは、各トラックごとに異なるAPIと状態定義を公開することです。そのため、真の統一性はなく、違いが開発者側に押し付けられるだけです。エンジニアリングチームは各トラック固有のロジックを記述し始め、運用チームはさまざまな障害モードを手動で処理し始め、財務チームは全く異なる経路をたどった類似のトランザクションを照合し始めます。
これは抽象化の漏洩です。本来は保護されるべきだったトラックの複雑さが、アプリケーション層に浸透し始めるのです。
トラックが増えるにつれて、決済環境は統一された抽象化ではなく、緩やかに接続された一連の統合へと変化していく。低速なトラックでは、遅延によって問題を検出するための時間的猶予が生まれる。しかし、リアルタイムのトラックでは、この猶予はなくなる。決済は数秒以内に完了し、エラーを容易に修正することはできず、資金移動後ではなく、移動前に意思決定を行わなければならない。
IV. リアルタイム決済は、決済サービスプロバイダーに管理の強化を促す。
リアルタイム決済ネットワークへの移行は、単に資金の流れを速めるだけでなく、決済インフラの設計要件を根本的に変えるものである。
ACH送金や電信送金の時代には、時間は緩衝材だった。
ACH取引は決済に数日かかる場合があり、銀行カード取引は承認後でも異議申し立てが行われる可能性があり、電信送金は多くの場合、手動による審査手順を伴います。これらの遅延は非効率性を招く一方で、エラーの検出、不審な活動への介入、決済確定前の照合完了といった機会も提供します。
従来のPSPモデルはこのバッファを中心に構築されている。

しかし、RTPやFedNowといったリアルタイム決済ネットワークは、この前提を完全に覆しました。資金は数秒以内に口座間で直接送金され、一度決済が完了すると、通常は取り消し不可能になります。
- 不正行為の検出はもっと早く完了させる必要がある。
- コンプライアンス審査はリアルタイムで実施されなければならない。
- 財務上の決定は、支払いが実行されたまさにその瞬間に行われなければならない。
- 後から間違いを訂正する機会はもはや存在しない。
即時決済を提供するプラットフォームは、遅延決済を前提としたワークフローに依存することはできません。複数の口座にわたる決済資金を管理する社内システムでは、決済実行時点での流動性を判断することはできません。また、基盤となる仕組み上、取り消しが不可能な場合、カスタマーサポートチームは取り消しを保証することはできません。
その結果、責任の所在が変化する。決済サービスプロバイダー(PSP)は、支払いのタイミングを決定する内部システムをサポートするように進化する必要がある。言い換えれば、管理権限を前者に移さなければならない。
決済インフラは、資金の流れの後ではなく、その前に承認、資金調達ロジック、リスクチェック、およびステータス検証が完了するように設計されなければなりません。そのためには、従来のPSPアーキテクチャでは提供できない、残高、取引ステータス、およびサービス提供者間の条件に関するより協調的なビューが必要となります。
リアルタイムの推移は最終状態ではなく、単なる転換点に過ぎない。ステーブルコインの導入は、この問題をさらに悪化させるだろう。
V. ステーブルコイン:新たな決済手段ではなく、新たな方向性
ステーブルコインに関する最も一般的な誤解は、それが新しい決済手段だと考えられていることです。しかし、そうではありません。ステーブルコインは、「取引の完了」から「資金の実際の受領」までの遅延を解消する、新しい決済手段なのです。
クレジットカード、ACH、電信送金とは異なり、ステーブルコインの取引はブロックチェーンネットワーク上で実行されます。
- 決済処理は継続的に行われており、一括処理は行われていません。
- (ネットワーク環境によっては)ほぼ瞬時に最終確認が可能です。
- 24時間365日稼働しており、銀行の営業時間や祝日の影響を受けません。
- 特定の国内決済システムに依存しない
- 残高、所有権、取引履歴を追跡するための基本要素は全く異なる。
従来のPSPアーキテクチャは銀行と決済ネットワークの統合を前提として構築されていますが、ステーブルコインはこれらの仲介者に依存しないネットワークを導入しています。発生、決済、会計処理はすべて、当初の設計とは別に行われます。企業は、銀行取引、リアルタイムネットワーク、オンチェーン決済を同時に調整する必要がある場合があり、それぞれが最終性、タイミング、制御に関して異なる前提を持っています。これらの違いを単一のAPIで統一することは不可能であり、PSPを単一の抽象化レイヤーとして維持することがますます困難になっています。
リアルタイム決済システムがタイミングや取消可能性に関する前提を覆すのと同様に、ステーブルコインは決済が行われる場所や方法に関する前提を覆す。
この過程で、彼らは新たな複雑さの層を導入する。
ステーブルコインサンドイッチは現在最も実用的な実装経路です。法定通貨の流入 → オンチェーンでの流通 → 法定通貨の流出。
取引の両端にいる顧客と供給者は、ステーブルコインを理解する必要はありません。ステーブルコインは単なる仲介チャネルであり、従来の国境を越えた決済における、時間のかかる、費用のかさむ、不安定なといった問題点を解決するために特別に設計されています。最も価値のある用途は、「アクセスが困難な」シナリオ、つまり従来の方法では時間がかかり、費用がかさむ、あるいはそもそも利用できないような国境を越えたシナリオに集中しています。
企業はステーブルコインに全面的に依存すべきではなく、また依存することもないでしょう。現実的なアプローチは、特定のユースケースを1つか2つ選び、部分的な代替として導入し、認知度を高めてから徐々に拡大していくことです。
ステーブルコインは、従来のシステムではほとんど存在しない、送金中の収益という新たな側面をもたらします。従来の決済プロセスでは、資金は発行から受取まで24時間から72時間拘束され、収益は発生せず、運転資金が滞留します。オンチェーンのステーブルコインは、流通中に収益を生み出すことができます。これは決済コストの微調整ではなく、資本効率の論理を根本的に再構築するものです。
VI. 現在のエコシステム:10層の分業と欠落した層
決済インフラがより多くの経路、より多くのサービスプロバイダー、そしてより多くのインフラタイプにまたがるにつれて、PSPの役割を定義することはますます困難になっている。
かつては単一の決済サービスプロバイダー(PSP)に集約されていた資金移動の責任は、現在ではテクノロジースタックの複数のレイヤーに分散された一連の責任となっている。
PSPの役割はもはや単に資金を移動させることだけではなく、資金の流れを解釈することにもある。
この変化は、より根深い変化を反映している。つまり、単に実行するだけではもはや十分ではないということだ。決済サービスプロバイダー(PSP)は、企業の内部システムをサポートし、資金がさまざまな環境間でどのように流れるかを表現、記録、照合できるようにする必要がある。

① 製品レベルのプラットフォーム:ソフトウェアへの決済機能の組み込み
Shopify、Square、Toast、Mindbody、ServiceTitan、Housecall Proといった業種別ソフトウェアプラットフォームは、自社製品に決済機能を直接組み込んでいる。
このようなシナリオでは、支払いは独立した決済システムとして処理されるのではなく、アプリケーション体験に統合されます。これらのプラットフォームは通常、基盤となる決済サービスプロバイダー(PSP)、銀行パートナー、およびインフラストラクチャサービスプロバイダーに依存しており、アプリケーションと資金の流れの間にさらに抽象化レイヤーが追加されます。
②実行レイヤー:クロストラックファンドの動き
テクノロジースタックの中核を担うのは、決済処理を担う決済サービスプロバイダーです。これには、Stripe、Adyen、Checkout.com、Worldpay、PayPal、Nuvei、dLocalといった従来型の決済サービスプロバイダーが含まれ、企業を決済システムに接続し、資金の移動を円滑化する役割を担っています。
これらは決済技術スタックの重要な構成要素ではあるものの、主に実行層(決済の開始、ステータスの報告、APIの公開など)で機能し、サービスプロバイダーや内部システム間で資金がどのように流れるかの完全なモデルを提供するものではない。
Stripeに「このお金は今どこにあるのか?」と尋ねても、Stripeは自社のセグメント内で何が起こったかしか教えてくれません。Stripeはチェーンの中の1つのノードに過ぎず、取引には決済サービスプロバイダー(PSP)、銀行、追跡システム、内部台帳など、他にも4つか5つのリンクが関わっている可能性がありますが、Stripeは全体像ではなく、その一部しか把握していないのです。
③ オーケストレーションおよびルーティング層:サービスプロバイダに接続します
企業が複数の決済サービスプロバイダー(PSP)や決済方法を採用するにつれ、サービスプロバイダー間のルーティングを管理するオーケストレーションプラットフォームが登場しました。Primer、Gr4vy、Spreedly、Paydock、CellPoint Digitalといった企業は、地理的な場所、コスト、パフォーマンスに基づいてトランザクションをオーケストレーションすることを企業に可能にしています。これらのシステムは実行レイヤーにおける柔軟性を高めますが、決済後の動作に関する統一モデルは提供していません。
④ リスク管理およびコンプライアンス層:資金を移動すべきかどうかを決定します。
独立したサービスプロバイダーのグループが、支払いの実行を許可するかどうかを決定する責任を負っています。Persona、Sardine、Alloy、Unit21、Sift、Sumsubなどのベンダーが提供する本人確認、不正検出、コンプライアンスシステムが、実行前にユーザーと取引を評価します。リアルタイム環境では、これらの決定は資金が移動する前に行われる必要があるため、重要な制御ロジックはPSP(個人サービスプロバイダー)の外部に移されます。
⑤ 銀行インフラ層:資金を保持し、アクセスをサポートする
Cross River Bank、Lead Bank、Column、Sutton Bankなどのカストディアン銀行は、規制対象の口座と決済ネットワークへのアクセスを提供します。これらの銀行は顧客資金を保有し、流動性を管理するとともに、ACH、電信送金、RTP、FedNowなどの決済システムへのゲートウェイとしての役割を果たします。このレイヤーは金融システムへのアクセスに不可欠ですが、アプリケーションロジックやPSP APIとは独立して動作します。
⑥ カード発行レイヤー:決済機能の拡張
Marqeta、Lithic、Rainなどのカード発行プラットフォームは、企業が自社製品の一部としてデビットカードやクレジットカードを発行することを可能にし、手数料管理、法人カード、市場支出といったユースケースをサポートします。これらのプラットフォームは銀行とカードネットワークを接続しますが、テクノロジースタック内で独立したレイヤーとして機能するため、追加のワークフロー、制御メカニズム、および状態が生じ、決済テクノロジースタックの他の部分との連携が必要となります。
⑦ 決済追跡レイヤー:基盤となる実行ネットワーク
決済経路とは、金融機関間で資金を移動させるためのネットワークのことです。従来型の決済経路には、ACH、電信送金、カードネットワークなどがありますが、RTPやFedNowといった新しいネットワークはリアルタイム決済をサポートしています。各決済経路は、タイミング、最終性、取消可能性に関して異なる前提に基づいており、決済サービスプロバイダー(PSP)は、これらの矛盾点を明らかにするか、あるいは(完全に抽象化するのではなく)回避する必要があります。
⑧ ステーブルコインネットワーク層:銀行インフラを超えた拡張
イーサリアム、ソラナ、ポリゴン、ベースなどのステーブルコインネットワークは、従来の銀行システムとは異なる新たな決済インフラを導入しました。これらのネットワークは、それぞれ異なる決済モデルとセキュリティメカニズムを備え、グローバルなインフラを通じてデジタルドルの送金を可能にします。銀行を介した決済システムの枠を超え、既存のワークフローに統合する必要のある新たな複雑さを生み出しています。
9. サービスとしてのバンキングレイヤー:アプリケーションと銀行の接続
Unit、Galileo、Treasury PrimeなどのBaaS(Bank-as-a-Service)プラットフォームは、フィンテックアプリケーションと規制対象の銀行を接続するインフラストラクチャを提供します。これにより、企業は銀行にならずとも、口座、カード、決済機能を提供できるようになります。このレイヤーは銀行インフラストラクチャへのアクセスを簡素化しますが、アプリケーション、決済サービスプロバイダー(PSP)、および基盤となる資金の流れの間に新たな仲介者を追加することになります。
⑩ 欠けているレイヤー:資金の流れのライフサイクル全体を網羅する統一されたPSP
上記の9つの階層を見ると、パターンは一貫している。各サービスプロバイダーは特定の機能を担当しており、資金の流れの全体像(理解、管理、照合を含む)を単独で提供できるプロバイダーは存在しない。
決済処理は1つのサービスプロバイダーが行い、リスク判断は別のサービスプロバイダーが行い、資金は銀行が保管し、決済プロセスはカードネットワーク、リアルタイム追跡システム、オンチェーンシステムにまたがる場合がある。各システムはそれぞれ異なるデータ、タイムライン、状態定義を公開する。
断片化された環境では、この問題は開始段階では顕在化せず、その後、システム内で意見の相違が生じ、資金の支払いが遅延または返金され、チームが回答を必要とする段階で顕在化します。まさにこうした状況で、決済システムは機能不全に陥り始めるのです。
VII. 決済処理はどこで失敗したのか?
金曜日の午後2時55分、経理チームはサプライヤーへの5万ドルの電信送金を依頼した。午後3時、銀行は送金を完了した。システム上では「送信済み」と表示されたが、確認メールは届かなかった。
午後4時、仕入先から支払い状況に関する問い合わせのメッセージが届いた。経理部が決済サービスプロバイダー(PSP)のバックエンドを確認したところ、「処理中」と表示されていた。一方、銀行口座を確認すると「決済保留中」と表示されていた。同じ金額なのに、システムによってステータスが異なり、どちらのシステムでも資金の所在が分からなかった。
金曜日の午後5時、銀行のカスタマーサービスはすでにその日の業務を終えていた。仕入先は週末の配送手配のために支払いを待っていた。経理チームは仕入先に何と伝えればいいのか、お金が月曜日の朝に自動的に入金されるのか、それとも返金されて再入金が必要なのか、見当もつかなかった。
これは極端なケースではなく、決済業務チームが毎週のように経験するシナリオです。決済サービスプロバイダーの製品マニュアルには記載されていませんが、すべての国際決済チームの業務記録には必ず登場するでしょう。
支払いに関する最も困難な問題は、多くの場合、開始段階ではなく、その後、つまりチームが何が起こったのかを正確に説明する必要がある段階で発生します。
前章で示した市場マップは、決済エコシステムの広がりを明らかにした。一見単純な決済であっても、決済が完了するまでに、テクノロジースタック内の複数のサービスプロバイダーを経由することが多い。各当事者は、同じ資金の流れであっても、異なるタイミング、異なる状態、異なるスケジュールで到着する書類、異なるチャネルを通じて報告される異常など、それぞれ異なる表現を持つ可能性がある。
まさにここから決済業務が難しくなるのです。
和解:同じ出来事の複数のバージョン
財務チームは、社内帳簿と銀行取引明細書、決済報告書、および処理業者データを照合する必要があります。あるサービスプロバイダーが支払いを完了済みと表示している一方で、別のサービスプロバイダーが処理中と表示している場合、会社は不一致を解消するためのモデルを必要とします。社内残高が更新された後にキャンセルが発生した場合は、帳簿をそれに応じて取り消すか調整する必要があります。
例外処理:明確な原因が特定できない障害
出金処理が失敗する原因としては、無効な送金先口座、誤った資金口座の使用、コンプライアンス審査による取引の一時停止、期限切れなどが考えられます。これらの失敗はそれぞれ異なり、同時に発生するわけでもありません。しかし、ユーザーは一貫した回答を期待しており、社内チームも処理プロセスを実行する必要があります。
流動性と資金調達:間違った場所に資金がある
複数のサービスプロバイダーやアカウントを横断して事業を展開する企業は、適切な資金が適切なタイミングで適切なアカウントにあることを確認する必要があります。たとえ十分な残高があっても、資金が間違ったアカウントに残っていると、支払いの実行が失敗する可能性があり、製品ロジックと実際の運用状況との間にギャップが生じます。
監査可能性と統制:何が起こったのかを再構築する
承認、保留、リリース、および照合といった一連の作業は、複数のチームやシステムにまたがって行われるため、企業は誰が、いつ、なぜ何をしたのかを確実に記録する必要があります。これはコンプライアンス要件であるだけでなく、問題が発生した場合に取引履歴を追跡するための基盤にもなります。
これらの問題は、運用面とアーキテクチャ面の両方に関わるものです。
決済業務における最大の失敗は、チームが「このお金はどこへ行ったのか?」という単純な質問に答えられない場合に発生することが多い。
不足しているのは、既存のモデル内で支払い処理、取引のルーティング、資金の保管を行う別のサービスプロバイダーではなく、これらの機能をすべて調整し、サービスプロバイダー間のステータスを追跡し、キャッシュフローのワークフローを管理し、長期にわたって信頼性の高い財務記録を維持できる、進化したPSP(決済サービスプロバイダー)である。
8. PSPの次なる進化
課題は決済インフラへのアクセスにあるのではなく、そのインフラ内で資金がどのように流れるかを、一貫性があり信頼できる形で把握し続けることにある。
現在のエコシステムは、決済サービスプロバイダー(PSP)が決済を実行し、銀行が資金を保有し、コンプライアンスシステムがリスクを評価し、オーケストレーションツールが取引をルーティングするという構造になっています。しかし、決済ライフサイクル全体にわたる資金の流れを完全かつ一貫して把握する責任を負う単一のサービスプロバイダーは存在しません。
PSPの次の進化は、テクノロジースタック全体にわたって一貫した可視性を提供することです。これにより、支払いの開始から最終決済までのすべての支払いが理解され、記録され、信頼できるものとなることが保証されます。
このレイヤーは以下のことが可能でなければなりません。
- 銀行、従来の鉄道、ステーブルコインネットワークを横断して決済を実行する
- 内部台帳を通じて、一貫性のある記録システムを維持する。
- 承認、資金、例外処理を管理するためのワークフロー
- 外部活動と内部財務状況を照合する。
- 規模が拡大するにつれて、コンプライアンス機能、アカウントインフラストラクチャ、そして継続的に拡大するトラック接続機能が組み込まれます。
結論:どこから始めればよいのか?
現代の決済インフラは、もはや単一のプロセッサや単一の処理経路によって定義されるものではありません。それは、資金の流れ、承認、決済、会計処理のさまざまな側面をそれぞれ担当する複数のサービスプロバイダーで構成される環境です。
このガイドを通して、私たちはこの環境の進化を見てきました。
決済サービスプロバイダーは取引処理の域を超え、決済経路は拡大し、リアルタイムシステムは決済遅延というセーフティネットを排除し、ステーブルコインなどの新しい形態のインフラストラクチャはシステム全体をさらに拡張している。
金融商品を開発したり、ソフトウェアに決済機能を組み込んだりするチームにとって、戦略的な議論よりも、参入点の方が重要だ。
ステーブルコインを全面的に導入すべきかどうかを議論することから始めるのではなく、具体的な問題点を特定しましょう。例えば、国境を越えた決済プロセスが遅すぎる、仕入先への支払いプロセスに手作業が多すぎる、遊休資金が送金途中で滞留し収益を生み出さない、といった問題です。ユースケースを選び、アカウントを開設し、実際に支払いを実行してみましょう。まずは社内で試験的に導入し、顧客側のプロセスを直接変更するのではなく、資金管理に焦点を当ててください。こうすることで、リスクを管理しながら認知度を高めることができます。
コンプライアンスの観点から言えば、KYC、AML、制裁スクリーニングの規則は引き続き完全に適用されます。ステーブルコインは、その基盤となるメカニズムの変更に過ぎません。GENIUS法制定後に確立された規制枠組みは、2年前よりもはるかに明確になっており、パイロットプログラムの実施を妨げる理由にはならないはずです。
真の戦略的リスクは、ステーブルコインを使うかどうかではなく、競合他社が決済コストと資本効率を再構築するためにステーブルコインを利用している一方で、あなたがまだ最適な参入機会を待っていることにある。
統一された調整層がなければ、規模が大きくなるにつれて複雑さが増します。しかし、それがあれば、企業は明確さ、統制力、そして自信を持ってキャッシュフローを管理できます。
一部コンテンツは「現代財務省 ― 2026年のPSP実践ガイド」から引用しています。




