要約

  • 9 月 9 日に発表された提携で、FinXP は Thredd のカード発行側の処理機能を取り入れつつ、自社の台帳と事業方針の管理を維持する。
  • FinXP は Thredd の顧客向けに欧州の BIN スポンサーとなる道も得る。採用する処理方式や契約条件、個別の稼働日程は明らかにされていない。

処理機能を外部から調達することと、決済事業の記録や方針を相手に委ねることは同じではない。FinXP と Thredd の提携は、その違いを明示した。Thredd が発行側の処理基盤を提供する一方、FinXP は自社の台帳とカード事業の戦略を引き続き管理する。ただし、台帳が手元に残るほど、外部で処理される取引との連携は重要になる。

9 月 9 日の発表には、デビットカード向けのトークン化、プロビジョニング、カード利用制御、不正・リスク対策、バックオフィスの自動化が挙げられている。これは提携で支える機能の説明であり、不正損失の減少や承認時間の短縮、取引単価の低下を測定した結果ではない。欧州と今後の成長市場を対象としているが、個別サービスの稼働予定は示されていない。

FinXP にとってカード発行は初めての事業ではない。発表によれば、すでに 5 年間の発行経験がある。9 月 3 日の事業紹介でも、カード発行と BIN スポンサー業務を決済サービスの一部として位置付けていた。今回変わるのは既存の構想を支える処理能力であって、発行事業を一から始めるという話ではない。

台帳の管理だけでは処理方式は分からない

Thredd の一般向け技術文書は、機能の分担に複数の選択肢があることを示している。Gateway Processing では外部ホストが残高を管理し、取引の承認を判断する。Full Service Processing では、その両方を Thredd が担う。これは選択可能な構成の例であり、FinXP がどちらかを採用した証拠ではない。

提携発表は、選ばれた方式、どの残高記録を各システムが扱うか、システムが利用できない場合の代行判断を明らかにしていない。したがって、台帳の管理を維持するという一文から、全取引を FinXP が承認するとは言えない。Thredd が運用上の残高情報を一切持たない、あるいは特定の代行承認が有効になるとも断定できない。

承認後にも処理は続く。同文書は、取引の承認と、その後のクリアリングや売上データの提示、最終的な資金の受け渡しを区別する。外部システムが関わる構成では、処理事業者から届く取引メッセージを対応する記録に反映させる必要がある。承認は最終的な資金移動そのものではない。台帳を維持しても、この対応関係を確認する作業は残る。

FinXP も相手に発行の入口を提供する

FinXP は処理機能を受け取るだけではない。提携によって Thredd の世界各地の顧客に対する欧州の BIN スポンサーにもなれると発表している。FinXP が発行への経路を、Thredd が処理基盤と顧客との接点を持ち寄る構図だ。単にソフトウェア会社を選ぶという説明では、この相互性が抜け落ちる。

FinXP のスポンサー業務の説明では、スポンサーとカードプログラムの運営者の役割を分け、開始前に設計、管理策、責任を合意し、案件ごとに評価するとしている。これは提供元によるサービスの説明であり、認可や規制上の資格を独立に確認したものではない。提携先の顧客網に接点ができることは、全顧客の承認や全地域での即時提供を意味しない。

料金、最低処理量、契約期間、移行日程は発表されていない。取引当たりの節減額や獲得済み売上を算出する材料はない。確認できる市場の動きは、FinXP が台帳と方針の管理を残して処理能力を加え、同時に相手の顧客へ別の発行機能を提供する点にある。