FinTechとBraze 口座開設オンボーディングとKYCステータス連携（概念）
目次 クリックで開く
FinTechサービスにおいて、ユーザーが最も離脱しやすいポイントは「口座開設」のプロセスです。特にKYC（本人確認）は、法律上の義務（犯罪収益移転防止法など）に伴う高いハードルがあり、ユーザーに多くの入力を強いるだけでなく、審査という「待ち時間」を発生させます。
この待機時間を「放置」するか、あるいはBrazeのようなカスタマーエンゲージメントプラットフォーム（CEP）を活用して「適切なコミュニケーション」へと変換するか。この差が、最終的な口座開設完了率、そしてその後のメインバンク/メインカード化（リテンション）に決定的な差を生みます。
本記事では、FinTechの実務担当者が直面する「KYCステータスとBrazeの連携」に焦点を当て、その具体的なアーキテクチャからシナリオ設計までを網羅的に解説します。
FinTechにおける口座開設オンボーディングの重要性とBrazeの役割
なぜ「KYCステータス」のリアルタイム連携がCVRを左右するのか
一般的なECやSaaSと異なり、金融サービスでは「会員登録」と「サービス利用開始」の間に数時間から数日のタイムラグが生じます。eKYC（オンライン本人確認）の普及により短縮されたとはいえ、書類の不備による差し戻しや、人手による最終確認は依然として存在します。
ここで重要なのは、ユーザーの熱量が最も高いのは「申し込んだ直後」であるという事実です。不備の通知がメールのみで、しかも数時間後に届くようでは、ユーザーは再申請の手間を嫌って競合他社へ流れてしまいます。Brazeを用いて、アプリ内メッセージやプッシュ通知で「今すぐ修正が必要な箇所」をリアルタイムに伝えることが、離脱を防ぐ唯一の手段です。
高度なデータ連携については、以下の記事でもデータ基盤構築の観点から触れています。
高額MAツールは不要。BigQueryとリバースETLで構築する「行動トリガー型LINE配信」の完全アーキテクチャ
カスタマーエンゲージメントプラットフォームとしてのBrazeの優位性
Brazeは、単なるメール配信ツールではありません。オーケストレーション機能（Canvas）により、ユーザーの行動や属性の変化をトリガーとして、プッシュ通知、メール、LINE、アプリ内メッセージを縦横無尽に組み合わせた配信が可能です。
特にFinTech実務において強力なのが「Connected Content」機能です。Brazeから外部APIを直接叩き、最新の残高情報や審査結果を取得してメッセージに動的に埋め込むことで、サーバーサイドの改修を最小限に抑えつつ高度なパーソナライズを実現できます。
KYCステータス連携のデータアーキテクチャ設計
Brazeへ連携すべき主要なKYCステータス一覧
オンボーディングを自動化するためには、少なくとも以下のステータスをBrazeへ同期する必要があります。
- applied: 申し込み完了（審査開始）
- pending: 追加書類待ち / 確認中
- rejected: 不備あり（要再申請） ※不備理由コードを付随させる
- approved: 審査通過（口座開設完了）
- denied: 総合的判断による謝絶
属性（Custom Attributes）かイベント（Custom Events）かの選定基準
Brazeへのデータ投入には2つの主要な形式があります。使い分けが設計の肝となります。
| 項目 | カスタム属性 (Attributes) | カスタムイベント (Events) |
|---|---|---|
| 役割 | ユーザーの「現在の状態」を保存 | ユーザーが「行ったアクション」を記録 |
| FinTechでの例 | 現在のKYCステータス、累計取引額 | 書類アップロード、審査通過の瞬間 |
| セグメント活用 | 「現在審査中の人」を抽出する | 「過去3回不備になった人」を抽出する |
| トリガー活用 | 不向き（変更を検知する設定が必要） | 最適（イベント発生の瞬間に配信） |
推奨設計：
現在のステータスは「Custom Attributes」で常に上書き更新し、ステータスが切り替わった瞬間（例：rejectedになった瞬間）に「Custom Events」を発火させてCanvasのトリガーにする、というハイブリッド構成がベストです。
セキュリティを担保するデータマスキングの実務
BrazeはSOC2やISO 27001などの認証を取得していますが、それでも金融機関として「個人を特定可能な情報（PII）」を外部のマーケティングツールに送ることは極力避けるべきです。
具体的には、以下のルールを徹底します。
- 名前、生年月日、住所、マイナンバーなどは絶対に送らない。
- Braze上の
external_idには、社内の内部顧客IDを（必要に応じてハッシュ化して）使用する。 - 不備理由は「住所が読み取れません」というテキストではなく、
err_001のようなコードで送り、Braze側のContent Blocksで文言に変換する。
名寄せやID連携の深い議論については、こちらが参考になります。
WebトラッキングとID連携の実践ガイド。ITP対策・LINEログインを用いたセキュアな名寄せアーキテクチャ
eKYCベンダーからBrazeへのデータフロー構築手順
KYCの審査は外部のeKYCベンダー（TRUSTDOCK、LIQUID eKYC、Proostなど）を利用するのが一般的です。これらのベンダーからBrazeへデータを流すには、中間サーバー（iPaaSや自社APIサーバー）を介した構築が必要です。
ステップ1：eKYCベンダーのWebhook受取サーバーの構築
多くのeKYCツールは、審査ステータスが変わった際に外部へ通知するWebhook機能を持っています。
- Cloud FunctionsやAWS Lambdaなどで、Webhookのリスナーを作成します。
- eKYCベンダーからのPOSTリクエストを受け取り、署名検証を行って正当なリクエストであることを確認します。
- ペイロードから「内部ユーザーID」と「新しいステータス」を抽出します。
ステップ2：Braze User Track APIを用いたデータ投入
抽出したデータをBrazeの /users/track エンドポイントへ送信します。
{
"api_key": "YOUR_REST_API_KEY",
"attributes": [
{
"external_id": "user_12345",
"kyc_status": "rejected",
"kyc_rejection_reason": "blurry_image"
}
],
"events": [
{
"external_id": "user_12345",
"name": "kyc_status_changed",
"properties": {
"from": "pending",
"to": "rejected"
}
}
]
}
ステップ3：不備理由（Rejection Reason）の動的マッピング
「書類が不鮮明」なのか「有効期限切れ」なのかによって、ユーザーが取るべき行動は異なります。BrazeのCanvas内で、 kyc_rejection_reason の値に応じて条件分岐（Current Value Check）を行い、プッシュ通知の文言を動的に変更します。
【比較】主要eKYCサービスとBraze連携の親和性
各社のAPI仕様を確認し、Brazeとの連携しやすさを比較します。
| サービス名 | Webhookの充実度 | Braze連携の難易度 | 特徴 |
|---|---|---|---|
| LIQUID eKYC | 非常に高い | 低（標準的なJSON） | 国内シェア高く、ステータス遷移が細かい。 |
| TRUSTDOCK | 高い | 中（API構造の理解が必要） | ID基盤としての側面が強く、データ連携オプションが豊富。 |
| Stripe Identity | 非常に高い | 低（Stripeエコシステム） | グローバル展開に強く、開発者ドキュメントが極めて優秀。 |
※各サービスの最新仕様・料金については、公式サイト（LIQUID / TRUSTDOCK）をご確認ください。
Brazeで実装する「離脱防止」オンボーディングシナリオ
【不備発生時】即時プッシュ通知による再申請プロンプト
審査不備が出た際、最もやってはいけないのは「翌朝にまとめてメールする」ことです。
Brazeのイベントトリガー配信を用いれば、システムが不備を検知した5分後に「写真のピントが合っていなかったようです。こちらから撮り直せます」といったプッシュ通知を送れます。Deep Link（ディープリンク）を活用し、通知をタップしたら直接アプリ内のカメラ起動画面へ遷移させるのが鉄則です。
【審査待ち期間】金融リテラシー向上コンテンツの教育配信
審査にはどうしても時間がかかります。この「空白の時間」に、サービスの賢い使い方や、セキュリティ設定の重要性を説くコンテンツをステップメール（Canvas）で配信します。これにより、開設後のアクティブ率を高めることができます。
【開設完了後】初回利用を促進する「マジックモーメント」への誘導
口座開設が完了した瞬間に「おめでとうございます！」で終わらせてはいけません。
「まずは1,000円を入金してみましょう」「最初の決済でポイント還元」といった、ユーザーがサービスの価値を実感する「マジックモーメント」へ誘導するシナリオを走らせます。
こうした一貫した体験設計（CX）については、以下の記事も非常に有用です。
広告からLINEミニアプリへ。離脱を最小化しCXを最大化する「摩擦ゼロ」の顧客獲得アーキテクチャ
よくあるエラーとトラブルシューティング
APIレートリミットによる通知遅延の回避策
キャンペーン等で申し込みが急増した場合、中間サーバーからBrazeへのAPIリクエストがレートリミット（制限）に掛かることがあります。
対処法：
中間サーバーにキューイング処理（AWS SQSなど）を実装し、BrazeのAPI制限（例：初期値では毎秒数万リクエストですが、契約プランによります）を超えないようにスロットリングを行います。
ユーザーID（External ID）の不一致問題
アプリ側でBraze SDKを初期化するタイミングと、サーバー側でKYCステータスを送り込むタイミングで external_id が一致していないと、データが紐付きません。
対処法：
ログイン後のトップ画面で必ず changeUser('内部ID') を呼び出す実装を徹底し、匿名ユーザーのままKYCが進まないようガードをかけます。
まとめ：FinTechのCXは「待機時間のデザイン」で決まる
FinTechにおけるBraze活用は、単なるメッセージ配信を超えた「製品体験の一部」です。KYCステータスという極めて動的なデータを、いかにユーザーのストレスを軽減するコミュニケーションに変換できるか。これが、熾烈なシェア争いを勝ち抜く鍵となります。
既存のSaaSコストやインフラの負債に悩まされている場合は、こうしたモダンなエンゲージメント基盤へ投資をシフトすることも検討すべきでしょう。
SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）
まずは、自社のKYCプロセスにおける各ステータスの遷移図を書き出し、どのタイミングでどのようなメッセージを送ればユーザーの不安を払拭できるか、マッピングすることから始めてみてください。