現場ノート

フィンテックアプリを始めるのに銀行免許は必要か

「フィンテックアプリを始めるのに銀行免許は必要か」という問いは、実は1つのコートを着た3つの問いです。顧客の資金を預かるのか。それを動かすのか。そしてその資金移動は、誰の規制上の許可でカバーされるのか。自社のものか、他社のものか。これに答えれば、免許の問いはほとんど自然に決まります。多くのチームが意外に思う結論は、大半のフィンテックアプリは銀行免許を持たないということです。銀行免許が本来必要となる行為を、大半のアプリは行わないからです。以下はスペクトラムの全体像であり、法的助言ではありません。誰かから期間や価格を提示される前に、どんな問いを立てるべきかを知ることが目的です。

銀行免許は本来何のためのものか

完全な銀行免許は、EU では信用機関の認可にあたり、厳重に管理された特定の活動を認めるものです。公衆から預金を受け入れ、その資金を貸し出すことです。長期の融資を、顧客がいつでも引き出せる残高で賄うという、この満期のミスマッチこそが、銀行に重い資本要件、預金保証の義務、そして貸借対照表を一行ずつ精査する監督当局が課される理由です。アプリが預金を受け入れず、それを元手に貸し出しもしないのであれば、検討すべきは銀行免許ではないはずです。スペクトラムのもっと軽い側にあるものを見ることになります。そして、そのスペクトラムこそが本題です。

許可の序列:重いものから軽いものへ

金融関連の許可は階層に分かれています。最上位は信用機関、つまり銀行で、預金の受け入れと貸出ができます。その下の電子マネー機関(EMI)は電子マネーを発行できます。顧客の価値を保管し、カードやウォレットに載せられますが、預かった資金は分別管理し、手を付けず、貸し出すことはできません。さらに下の決済機関(PI)は決済を実行できます。送金の指図、収納、送金サービス、カード取引のアクワイアリングなどが対象ですが、価値を長期間保管する設計ではなく、資金は通過するだけで滞留しません。最下層の代理店・販売代理人は自らのライセンスを一切持たず、自身を登録した認可事業者の権限のもとで事業を行います。

段を下りるごとに、できることが減り、それに伴って必要な資本と義務も軽くなります。預金を扱うことは許される中で最も重く、それができる事業者の代理店になることは最も軽い立場です。ウォレット、カード、送金、決済リンクといった消費者向けフィンテックアプリの多くは、EMIや決済機関の範囲、あるいはそのいずれかを持つパートナーの上で成り立っています。銀行になる必要があるケースはごくわずかで、それを早く見極めれば、見当違いの労力を大幅に省けます。

自社の位置を確かめる簡単な方法があります。顧客がアプリ内で残高を保有するなら(チャージするウォレットや、事前入金するカードなど)、そこは電子マネーの領域です。価値の保管こそがEMIを定義する許可だからです。資金が通過するだけなら(送金の指図、請求の収納、支払いのそのまま引き渡しなど)、決済機関の許可が自然な選択となり、自社で持つか、パートナーに持たせます。資金に一切触れず、他で保有されている口座の情報を表示するだけなら、それにも軽い登録制度があります。立場が重いほど、必要な資本と監督も重くなります。設計の目標は、プロダクトが実際に必要とする以上に重い位置に立たないことです。

許可を借りる:パートナーモデル

許可は自社で保有しなくても、その上にプロダクトを構築できます。一般的なのは借りる方法です。スポンサーバンクやBanking-as-a-Service(BaaS)の契約では、認可を受けた銀行またはEMIが口座を保有し、IBANとカードを発行し、預かり資金を分別管理します。皆さんはその API に対してアプリを構築し、体験を提供します。代理店モデルでは、決済機関の代理店、または電子マネー発行者の販売代理人として登録し、その事業者のライセンスが皆さんの活動をカバーします。規制当局は、その事業者を通じて皆さんを把握します。契約は異なっても、根底にある事実は同じで、スタックのどこかで誰かが許可を保有しています。問題は、それが自社なのかパートナーなのか、ただそれだけです。

誰がどの責任を負うのか

ライセンスを借りても、責任まで手放せるわけではありません。規制当局に対して責任を負うのは認可事業者であり、顧客資金の分別管理、マネーロンダリング対策のモニタリング、プログラム全体の運営がその対象です。ただし、これらの義務は契約によって下流へ流れます。パートナーのライセンスに乗る場合でも、KYCとオンボーディングは自社で実施し、AMLのための取引監視も行い、パートナーが課せられている限度額や報告も守る必要があります。責任は外部に委託されるというより、分担されます。パートナーは規制当局に対して責任を負い、皆さんに対しては契約で責任を負わせ、日々の義務の多くを皆さんの側に戻します。その契約は、取得しないと決めたライセンスを読むのと同じくらい注意深く読んでください。

ライセンスは、他人のお金を保有または移動させるための許可です。ソフトウェアは、そのお金に指図を出し、照合し、顧客に表示するための手段です。両者は1社から買うことも2社から買うこともできますが、買うのは常に両方です。
— Protocore · 決済エンジニアリング

ソフトウェアとライセンスは別々の購入

これはプロジェクト全体の見方を変える洞察です。決済アプリは顧客から見ると1つのものに見えますが、実際は2つが融合しています。お金を保有または移動させる規制上の許可と、その移動を指図し、台帳を保持し、入金を照合し、画面に残高を表示するソフトウェアです。この2つは別々に調達します。自社でライセンスを持ってソフトウェアを購入する、ライセンスを持ってソフトウェアを内製する、パートナーを通じて許可を借りてその上でソフトウェアを購入する、あるいは両方をまとめて提供するベンダー1社から調達する。この4つはいずれも普通のことです。普通ではなく、静かにプロジェクトを数か月遅らせるのは、両者の混同です。BaaSパートナーとアプリが必要だったのに「銀行ライセンス」を探し回る、あるいは許可がアプリに最初から付いているものと思い込んでアプリを探す、といったことです。

別々の購入として捉えると、価格とスケジュールを個別に検討できるため、見通しが明確になります。ソフトウェアは、オンボーディングのフローが機能するか、台帳が正確か、オペレーターが実際に運用できるかといった実力で評価できます。許可のほうは、管轄、分別管理、契約条件で評価します。Protocore Pay (/products/pay) は、ソフトウェア層だけを提供する一例です。持ち込まれたあらゆる規制対象のレール上で動作する、whitelabelのアプリプラットフォームとオペレーターコンソールです。これはライセンスではなく、どんなソフトウェアもライセンスにはなりません。だからこそ、ライセンスは計画の中で別項目として残るのです。

プラットフォームベンダーに確認すべきこと

「フィンテックを立ち上げよう」と提案してくるプラットフォームには、同じ短い質問リストで曖昧さの大半を解消できます。御社のプロダクトには規制上の許可が含まれていますか、それとも自分で用意するのですか。含まれている場合、それは誰のライセンスで、どの国のもので、自分はその事業者の直接の顧客ですか、それともその代理店の顧客ですか。顧客資金は誰が分別管理し、どこに保管されますか。マネーロンダリング対策で規制当局に届け出られているのは誰ですか。自分、パートナー、それとも御社ですか。ライセンスが自分のものでないにもかかわらず、契約上どの義務が自分に課されますか。そして提携が終了した場合、顧客の資金とデータはどうなりますか。回答次第で、ベンダーは、ソフトウェアを売る会社、パートナーの許可を再販する会社、両方を本当にまとめて提供する会社のいずれかに素早く仕分けられ、相手がどれなのかも分かります。

心強いことに、ほとんどのアプリは、ソフトウェアにパートナーの許可を組み合わせて始まり、取引量、利益率、戦略の面で資本とコンプライアンス人員に見合うようになって初めて、自社ライセンスへと進みます。自分が本当に必要な段がどこかを知り、ソフトウェアと許可が別項目で購入されることを理解していれば、課題の大半は解決したも同然です。残りは、上記の質問をして、回答を丁寧に読むことです。ここに書いた内容は法的助言ではなく、基準値やカテゴリー名は管轄によって異なります。規制当局や専門家との会話に持っていく地図として使い、専門家の代わりにはしないでください。

システム開発をご検討中ですか?

課題をお聞かせください。アーキテクチャと計画をご提案します。