ドメイン駆動設計と決済の未来

これまで銀行の決済オーケストレーションプラットフォームは、特定の決済ネットワークの要件を満たすために、個別のシステムが集まったものとして進化してきました。

その結果、フロントエンドチャネルアクセスの集約、銀行の基幹システムとの統合、請求処理、そしてこれらのシステム全体にわたる分析の実行が困難になっています。新しい規制要件への対応や、顧客体験を向上させるための新機能追加が必要な場合、多大な時間とリソースが消費されます。新しい決済ネットワークやユースケースへの対応には、多くの場合、多額の投資と業務の中断が伴います。また、複数のシステムを運用する必要があるため、ライセンス費用や運用サポートといったコスト面での課題も生じます。

銀行は、現金、小切手、電信送金といった従来の方法から、デジタル決済、モバイル決済、Eコマース決済といった新しい方法まで、多様かつ複数の決済手段を扱うという課題に直面しています。決済手段ごとに独自の特性があり、それをサポートするために異なるシステムやプロセスが必要となるため、結果として一般的な決済スタックは複数の決済プラットフォームで構成されることになります。

銀行が決済プロセスを単一のプラットフォームに統合したいと考えるのは当然のことです。そうすることで、銀行は運用効率とコスト効率を高め、サイバーセキュリティや規制コンプライアンスのリスクを低減し、摩擦のない顧客体験を提供できるようになります。

‍

‍

しかし、多種多様で断片化された決済手段、スキーム、タイプを単一のプラットフォームに統合することには課題があります。

決済手段によってビジネス要件やコンプライアンス基準、手順が異なるため、技術的な検討事項が増加します。例えば、クレジットカードプロセッサは、数百ミリ秒以内に承認リクエストに応答できなければなりません。また、カードスキームの保証についても把握しておく必要があります。

対照的に、口座振替バッチの処理は時間に敏感ではありませんが、プロセッサは決済送信のスケジュールを管理し、数日かけて決済を完了させる必要があります。RT1やFedNowのような現代の即時決済システムは単一のISO 20022メッセージを使用しますが、BACSやACHのような古いシステムは独自のフォーマットのファイルを使用します。

今日の急速に進化し複雑化する金融の世界では、今後どのような新しい決済手段が登場するかを予測することは不可能です。そのため、あらゆる決済手段に接続できる決済システムを見つけることは銀行にとって困難です。過去2年間に登場した決済手段を見れば、そのことは明らかです。

そこで、本稿の核心となるポイントを述べます。銀行には、スタックを簡素化し、所有コストと変更コストを削減すると同時に、決済の挙動を完全に制御し、将来を見据えた柔軟なソリューションを構築して、新しい決済手段の追加やイノベーションを可能にする、単一の決済オーケストレーションシステムが必要です。

汎用的な設定可能オーケストレーションエンジンを備えた軽量な接続コンポーネント

単一のボックスにすべてを統合することは不可能です。ほとんどの決済システムへの接続には依然として専用のハードウェアとソフトウェアが必要であり、それらを複数のレール間で共有する機能は限定的であるか、あるいは存在しないためです。

したがって、各決済システム専用の接続コンポーネントを維持するのが合理的です。これらのコンポーネントは可能な限り「軽量」であるべきであり、接続プロトコルと変換のみを担うことで、共通機能はエンジン側で提供し、各決済システムのコネクタで重複させないようにする必要があります。

‍

‍

銀行が独自の決済オーケストレーションを構築できるようにする

さまざまな種類の決済のライフサイクルをオーケストレーションする際の課題は非常に大きいものの、克服不可能なものではありません。すべての決済は、本質的には「ある口座から別の口座への資金移動」という点で共通しています。そうであれば、決済タイプごとに専用のソリューションが必要なのでしょうか？複数のフローをサポートできるソリューションを構築し、さらにユーザー自身がそれらのフローを作成できるようにすることは可能ではないでしょうか。

私たちが決済においてこれをどのように実現したかを見る前に、全く異なる分野であるビデオゲームの例を見てみましょう。

ゲーム開発の黎明期には、エンジニアは物理シミュレーション、レンダリング、接続性、スクリプトシステムといった機能をサポートするために、技術をゼロから構築しなければなりませんでした。このプロセスは労働集約的であり、高度なプログラミングの専門知識と、基盤となるハードウェアへの深い理解が必要でした。

しかし今日では、UnrealやUnityのようなゲームエンジンが、ゲーム作成のための事前構築されたフレームワークを開発者に提供することで、ビデオゲームの制作方法を一変させました。これらのエンジンには、物理シミュレーション、レンダリング、スクリプト作成など、多くの機能が含まれています。開発者はこれらの機能を利用することで、ゲームエンジンが提供する基盤技術を活用したスクリプトを使い、ゲームロジックの構築により多くの時間を割くことができるようになりました。

ゲームエンジンは汎用的なソフトウェア構築ツールではありません。ゲーム制作に特化した一連のツールを提供することで、必要とされる基本的なツールが共通しているため、全く異なるジャンルのゲームを構築することを可能にしています。

ゲームはリソースを大量に消費するため、汎用エンジンで期待されるパフォーマンスを実現できるのかという疑問が生じます。実際には、これらのエンジンはその分野の専門家によって構築・最適化されているため、ほとんどの開発者が独自のカスタムエンジンを構築する場合よりもはるかに優れたパフォーマンスを実現しています。

上記のアプローチは決済にも適用できます。銀行が決済オーケストレーションを迅速かつ容易に構築できるようになるため、すべてをゼロから作り上げるために大勢のエンジニアを抱える必要はありません。

ドメインへの理解

決済処理の共通点として、コンベアシステムが決済をあるワークステーションから次のワークステーションへと移動させる「生産ライン」のようなものだと考えることができます。決済の場合、どのワークステーションを使用し、どのような順序で進めるかは決済タイプによって異なります。そのため、当社の決済プラットフォームは、ユーザーが独自の決済生産ラインを構成できるようにする必要があります。

これを聞くと、ワークフローエンジンが適しているように思えるかもしれませんが、実際には全くそのようなことはありません。

まず、決済エンジンには高いパフォーマンスと信頼性が求められ、サービスレベルアグリーメント（SLA）に基づいて決済を動的に優先順位付けする必要がありますが、ワークフローエンジンではこれが実現できません。さらに、決済エンジンは決済ドメインを理解し、開発者が決済タイプを横断して使用できる特定のツールを提供する必要があります。そうでなければ、それらのツールを構築するのはユーザーの負担となってしまいます。

例えば、決済処理の基本的なステップには、検証、承認、クリアリング、決済があります。各ステップには状況に応じた特定の要件やプロセスがありますが、最終的にはすべて、取引を成功させるという同じ目標に向かって機能します。

‍

前述の例で取り上げた決済方法、カード承認と口座振替に立ち返ってみましょう。本質的に、どちらも顧客が加盟店に対して口座からの引き落としを許可するという意思表示を表しています。そのため、これらの処理手順が非常に似ていることは驚くべきことではありません。

1. 決済ネットワークからメッセージを取得する
2. 既存の承認データ記録と照らし合わせて取引を検証する
3. 不正検知エンジンに照会し、顧客が実際にその支払いを承認したかどうかを確認する
4. 管理ルールを適用する（取引の回数や種類に制限を設けるなど）
5. 顧客の口座に支払い可能な残高があるかを確認し、決済のために資金を確保する

顧客が口座から送金を行う振込指示についても、プロセスには共通点が見られます。支払いには不正の可能性がないか審査が必要であり、顧客には支払いを行うための十分な残高が必要です。この決済タイプでは、送金先の検証、処理日の計算、場合によっては手数料の割り当てなど、他のステップも必要となります。

現代の決済システムは、決済ドメインを認識しつつも、特定の決済タイプに依存しない真のプラットフォームであるべきです。すべての決済タイプを共通の標準（現在、世界的なデファクトスタンダードとなっているISO 20022など）で表現し、一般的な決済処理ステップをビルディングブロックとしてカプセル化する必要があります。これにより、ユーザーはそれらを適切な順序で構成し、ユーザーや決済システム固有のロジックを組み込むことが可能になります。

これらすべてを実現しつつ、決済プラットフォームのパフォーマンスと信頼性を維持しなければなりません。決済タイプに依存せず、同一のエンジンですべてを処理しながらも、それぞれの期待されるSLAに基づいて優先順位を付けることができる必要があります。

‍

‍

決済を取り巻く環境は急速に変化しており、新旧の手法が混在する中で、顧客の期待も新たなものへと変わっています。消費者は今、さまざまなデバイスから簡単にアクセスできる、シームレスで便利かつ安全な決済体験を求めています。

フィンテック企業や銀行以外の決済サービスプロバイダーの台頭が、この課題をさらに複雑にしています。彼らは多くの場合、より革新的で顧客中心のソリューションを提供しており、従来の銀行サービスから顧客が離れる要因となっています。

この傾向に対抗するため、銀行はテクノロジーへの投資を優先し、変化する決済環境に対応して、顧客が期待する利便性とセキュリティを提供しなければなりません。これらの期待に応えられなければ、顧客の流出や市場シェアの低下を招く恐れがあります。

決済レールはますますコモディティ化しており、特定の決済スキームと通信するための単なる接続メカニズムとなっています。将来の決済システムの真の力と柔軟性は、複数の決済ソースにわたる決済フローを効果的に管理・合理化できるオーケストレーションエンジンにあります。

オーケストレーションエンジンは決済システムの頭脳であり、企業が決済業務を最適化しながら、顧客に最高の決済体験を提供することを可能にします。

効果的なオーケストレーションエンジンを活用することで、企業は決済フローのカスタマイズやリスク管理、リアルタイムでの決済インサイトの把握が可能になります。

最新の決済エンジンを適切に評価するには、特定の既知のシナリオへの適合性だけを判断するのではなく、利用可能なツールや多様なユースケースへの対応能力を考慮した包括的なアプローチをとるべきです。既存の製品の枠にとらわれず、将来を見据えた視点を持つことが重要です。

新しい決済手段の導入や、複数の決済モード間の相互接続性を促進するには、決済手段に依存せず、ISO 20022に準拠し、高いパフォーマンスと信頼性を備えた、必要なリソースを完備した決済エンジンを選択するのが賢明です。

最終的に、理想的な決済エンジンとは、パフォーマンスや信頼性を犠牲にすることなく、比類のない構成の柔軟性を実現するものです。