ニッチな需要かもしれませんが、自社プロダクトからユーザーへ入金処理が発生する場合、プロダクト上で銀行口座の情報を取得する必要があります。

これが非常に面倒です。今後、僕以外のデザイナーが少しでも楽にデザインを行うことができるように注意すべきことをまとめておきます。

長くなってしまうため、こちらの記事はあくまでUIを考える上で必要になる情報をまとめたものになります。なぜそのUIなのかという説明までは行いません。

必要な情報

まずは入金処理・入金代行処理をするにあたり、必要な情報を出しておきます。必要な情報は下記です。

入金処理を行う際は、送金を代行してくれる外部サービスを使うことが多いと思います。この場合、流れは下図になります。

口座番号の桁数などの詳細な仕様は、送金代行サービス側で定義されています。デザイナーはこの仕様に合わせて、ユーザーが情報を入力できる場を提供することになります。仕様をエンジニアと一緒に把握しておきましょう。(自社で送金作業まで行う場合はこの限りではありません)

結論

結論を先に記載しておきます。

• 銀行名は選択肢を用意した方が良いが、すべての銀行を網羅するのはコストが高い。自社プロダクトで対応すべき範囲を考える必要がある

• 支店番号は数字で入力してもらう

• 預金種類は「普通」をデフォルトで選択状態にし、「当座」と「貯蓄」も選べるように

• 口座番号は基本7桁だが例外もあるため、何桁で入力してもらうか決める必要がある

• 給与として支払う場合は口座名義が労働者本人であるかの確認を行う必要がある

• 手数料についての取り決めを記載しておく必要がある

具体的なデザインに落とし込んだ場合、このような形になります。

銀行名について

銀行名は最終的に「金融機関コード」または「銀行コード」と呼ばれる4桁の番号に変換して送金代行サービスに渡す必要があります。

しかし、ユーザーに金融機関コードで入力させるのはハードルが高いです。一般の方で「みずほ銀行」の金融機関コードが何番なのか把握している人はほとんどいないでしょう。 (みずほ銀行のコードは0001です。観測範囲では1社のみ通帳等に記載があるようですが、例外と考えて良いと思います)

一方で、銀行名から金融機関コードに変換するために、信用できる公式な情報を取得しようとすると、全国銀行協会が出しているCD (windowsのみ対応) を月に約5万円支払って使用する必要があるようです。高い…。

非公式の物もありますが、ネット銀行など、支店が比較的簡単に増えるものへの対応に不安があります。上記の条件を踏まえ、関係者間で自社のプロダクトで対応するラインの認識を合わせておきましょう。
銀行名の取得方法は下記3パターンが考えられます。

1. 選択式

2. フリーテキスト式

3. コード入力式

それぞれメリット・デメリットを見ていきましょう。

1. 選択式

銀行名をリストで表示し、その中から選択してもらうパターンです。

現実的なのは都市銀行とゆうちょ銀行のみ選択肢を用意しておき、それ以外のネット銀行や地方銀行、信金は一旦対応しない (対象の銀行で口座を作ってもらう) という形です。

これであれば6つの銀行にだけ対応を行えば良いため、手運用でも対応が可能そうです。対応銀行を減らす事は難しいですが、増やす事は比較的簡単 (監視コストは上がってしまいますが) なので、プロダクトの成長に合わせて地方銀行やネット銀行などを追加していく形をオススメします。

6つの銀行だけだと大部分の人が漏れてしまうのでは？という疑問は当然あると思います。下記2つの調査結果をご覧ください。

調査結果から、下記がわかります。

上記を踏まえると、大半の方が6銀行のうちどこかに口座を持っていると考えて良いのではと感じます。残りの数％をどう捉えるかはプロダクトによって異なりますが、対応範囲を広げていけることを踏まえると初期の対応としては十分な数字ではないでしょうか。

2. フリーテキスト式

入力フォームにテキストで銀行名を記載してもらうパターンです。

上記の問題をどう吸収するのかを考えておく必要があり、対応が複雑になり現実的ではありません。結局裏側で人間が頑張ることになり、スケールするとコストが上がって死んでしまいます。(経験済)

3. コード入力式

ユーザーに自力で金融機関コードを調べてもらうパターンです。冒頭で否定しましたが、場合によってはベストな選択肢になりえます。

最速で実現できるメリットはありつつも、調べることを強制するため、なるべく避けたいパターンです。プロダクトから一度離脱しなければならないストレスは大きいと思います。

ただし、要求仕様として「全銀行に必ず対応すること」が含まれている場合はこちらの採用を検討するべきでしょう。その場合は公式の金融機関コード一覧へのリンクを追加してください。

上記を踏まえ、1の選択式でプロダクトに合わせて対応範囲を調整する方法をオススメします。比較的コストが低く、プロダクトに合わせて柔軟に対応が可能です。

支店番号について

支店番号という3桁の数字が必要です。名称が「店番」「支店コード」となっている場合があります。

支店名を直接選択してもらう、または入力してもらう場合もありますが、銀行名と同じくプロダクト内で番号に変換をして送金代行サービスに渡すことになります。支店番号の取得方法は下記2パターンが考えられます。

1. 支店番号入力式

2. 支店名選択式

こちらもメリット・デメリットを見ていきましょう。

1. 支店番号入力式

支店番号をそのまま入力してもらうパターンです。

デメリットとしましたが、支店番号は金融機関コードとは違い、手元に用意をしているキャッシュカードや通帳に番号の記載があるため、入力時のハードルは低いです。

他の番号と間違えることを防ぐために、フォーム自体を3つに分割して桁数を伝えたり (Androidの場合は実装が面倒になるので避ける方が良いです)、カウンターで文字数制限を伝えたり、バリデーションをかけることでミスを減らすことができるでしょう。

2. 支店名選択式

支店名の選択肢を用意してその中から選んでもらうパターンです。

数が膨大になるため、前述の公式情報を用意できない場合は無理をして採用しない方が良いでしょう。上記の理由から1の支店番号を直接入力してもらう形式をオススメします。

預金種類について

預金の種類は複数存在しますが、特殊な業態を除けば、普通・当座・貯蓄を扱っていればほぼ全てのユーザーをカバーできるはずです。「貯蓄」は選択肢に無いサービスも見かけます。

ほとんどの場合「普通」を選択することになるので、デフォルトで「普通」を選択した状態にしておくと親切です。

口座番号について

2011年11月以降、普通預金の口座を作ると番号は7桁になるよう統一されました。これはゆうちょ銀行を除く全ての銀行・信用金庫で運用されています。

問題はゆうちょ銀行をはじめとする例外が存在することです。ゆうちょ銀行は8桁、その他の銀行でも7桁に統一される前に作られた古い口座では2〜6桁の場合が存在します (地獄) 。

なおかつ送金代行サービス側は7桁の口座番号が来ることを前提としている場合があり、自社プロダクト側で口座番号を7桁に変換する必要があります。

対処法のルール

とはいえ、対処の方法にはルールが存在します。ゆうちょ銀行の場合は番号の最後に必ず「1」が入ります。そのため、7桁にする際に最後の「1」を抜いて番号を入力してもらうことになっています。

また、古い口座で桁数が足りない場合は「0」を番号の左側に追加して7桁にすることになっています。

情報入力の形式

具体的には下記の方法が考えられます。対応の深さでレベル分けをしています。

1. 入力を4~8桁まで許可し、人力オペレーションで7桁に変換する

2. 入力を7桁に限定し、ユーザーが自ら口座番号を7桁にするサポートのみを行う

3. 入力を4~8桁まで許可し、システム側で変換を行う

セキュリティの観点から言うと1はリスクが伴います。もしどうしてもこの方法を取らなければいけない場合、名前と支店番号をマスクした状態で口座番号のみが見える仕組みにし、最小の人数で厳しいルールのもと運用、最短でLv2かLv3に切り替えていく必要があります。（この時点でコストの低さというメリットが消えていますが）

3を目指しつつ、直近で捌かなければいけない件数やオペレーション体制など、自社のプロダクトで今どの形式が良いのかを判断しましょう。

口座名義について

セイメイを入力してもらう必要があります。入力フォームをセイとメイの2つに分けておきましょう。

こちらも、送金代行サービスによって仕様が異なるため確認が必要です。送金代行サービス側で入力が許可されている文字が半角カナのみの場合は、プロダクト上で入力された文字を変換してあげる方が親切でしょう。

注意すべきこと

売上金の振り込み等の場合は問題ないのですが、労働の対価である給与の振り込みに関しては労働基準法により労働者本人に直接お金を振り込む必要があります。

労働基準法第24条に直接払いの原則が存在するため、本人以外の口座に給与を振り込むことはできません。そのため、本人確認を行う義務が発生します。 

本人確認書類を提出してもらい、そこに記載された名前と、口座名義が一致しているかを確認する必要があります。

本人確認書類を提出してもらうと同時に、本人確認書類上に記載された氏名を入力してもらいましょう (確認の際に確認者が入力を代行する方法もあります)。この情報を使って、口座名義と一致するかを確認します。

通名・ミドルネームの対応

口座名義が本人であってもプロダクト上で入力された情報と一致しない場合があります。

在日外国人の方の場合、本人確認書類に通名が併記されている場合があり、この場合は口座開設時に本名か通名のどちらを使用するかを選択することが可能です。

プロダクト上では通名を使いたいが口座は本名で開設している、と言った場合、プロダクト上でも本名を使ってもらうことになります。

また、ミドルネームが存在する方もいらっしゃいます。入力フォームがセイとメイのみの場合、ミドルネームをどちらに入力したら良いか、それとも省略すべきなのかがわからなくなるはずです。

例えば、本人確認書類上の本名が「マイケル・アンドリュー・フォックス」だったとします。

この場合、口座を作成した際の名義登録方法に依存します。日本の銀行で口座を作る場合も、入力欄はセイとメイのみなため、省略するかセイ・メイのどちらかにまとめて記載するように求められます。

このように口座開設時に設定していた場合は、プロダクト上の名義情報もこれに合わせる必要があります。

この場合、口座名義として登録された名前が英字である場合もありますが、基本的にはカタカナで入力するものなので、英字を許可するかどうかはプロダクトのユーザー層を考えて決める必要があります。

情報をまとめることを主眼においているため記載を行いましたが、ここまでプロダクト上で対応すべきなのかは疑問があります。オペレーションに接続し、個別で対応を行う方がコストは低いため、判断が必要です。

ミスによる手数料の取り扱いについて

口座情報の入力ミスによって入金できなかった場合、入金代行サービスを提供している運営会社から手数料を請求されます。

これをユーザー持ちにするのか自社で負担するのかを決めておく必要があります。

前者の場合は口座情報が登録される前に、「入力ミスがあった場合は〇〇円を負担してもらう」ことについてユーザーに同意してもらう必要があるため、必ず目に触れる場所に記載を行うようにしましょう。

最後にもう一度結論をまとめ

• 銀行名は選択肢を用意した方が良いが、すべての銀行を網羅するのはコストが高い。自社プロダクトで対応すべき範囲を考える必要がある

• 支店番号は数字で入力してもらう

• 預金種類は「普通」をデフォルトで選択状態にし、「当座」と「貯蓄」も選べるように

• 口座番号は基本7桁だが例外もあるため、何桁で入力してもらうか決める必要がある

• 給与として支払う場合は口座名義が労働者本人であるかの確認を行う必要がある

• 手数料についての取り決めを記載しておく必要がある

以上が口座情報を入力してもらう際に気をつけることでした。長すぎる…
最後までお読みいただきありがとうございます。

あなたのプロダクト作りをお助けできたらうれしいです！