暗号資産ネオバンクのバックエンドを1本のkeyで構築する
銀行口座と暗号資産ウォレットを1つのアプリに収めるネオバンクでは、残高表示・入出金のスクリーニング・出金処理という3系統を、いかに監査可能でシンプルなバックエンドにまとめるかが設計の中核になります。ここでは、口座ごとのnet-worth (BTC/ETH/TRON) の読み取り、on-ramp/off-rampでのrisk-scoreとKYT、そしてmass payoutによる出金を、すべて1本のkeyと1つのcredit残高の上で組み立てる構成を示します。
課題
一般的な構成では、balancesを取得するAPI、資金の入出金をスクリーニングするベンダー、出金を実行するpayoutレールで、それぞれ別々の契約と別々のkeyが必要になります。3つの請求体系と3つの障害点を抱え、どのベンダーがどこまでの資金を見ているのかという境界も曖昧になりがちです。運用上とくに悩ましいのは、スクリーニングを「いつ」行うかです。資金の入金・解放の判断はrampの境界で下す必要があり、その後の定着したアクティビティは別のロジックで監視し続けなければなりません。
- Balances / portfolio / net-worthC2
- Address risk-score / exposureC3
- Transaction screening / KYTC3
- Mass payout / settlementC2
口座別net-worthを1回の読み取りで集約する
各ユーザーが保有するBTC/ETH/TRON上の残高を、口座単位で1回の読み取りにまとめます。チェーンごとにRPCを叩き分けてパースするコードを自前で持たずに済むため、口座画面のバックエンドは残高表示のロジックに集中でき、新しいチェーンを足すときも読み取り側の実装が肥大化しません。
rampの境界でrisk-scoreとKYTを使い分ける
on-ramp/off-rampで資金が動く瞬間には、その資金を入金・解放してよいかをrisk-scoreで判断します。ここが「解放前」の関門です。判断が通ったあとは、口座に定着したアクティビティをKYTで継続監視し、事後に浮かび上がるリスクを拾います。解放前の一括判定と、その後の継続監視を役割分担させることで、どの時点でどんな根拠で判断したかが監査で追える構造になります。
出金をmass payoutで同じ残高から実行する
ユーザーへの出金は、一括送金の仕組みで処理します。balancesの読み取りとpayoutが同じcredit残高を共有するため、残高照会用と送金用でkeyを分ける必要がなく、請求も一本化されます。署名はクライアント側に残り、keyがユーザー資産の秘密鍵を預かることはありません。
この構成が提供するもの
- balances・スクリーニング・payoutの3つを1本のkeyと1つのcredit残高に統合し、契約と障害点を減らせる。
- 解放前のrisk-scoreと事後のKYTを役割分担させ、判断の時点と根拠を監査で追える構造になる。
- 口座別net-worthの読み取りと出金が同じ残高を共有し、残高照会と送金でkeyやベンダーを分けずに済む。
よくある質問
秘密鍵の管理はどうなりますか。keyを渡すと資産を預けることになりませんか。
署名はクライアント側に残ります。ここで言うkeyはAPIアクセス用のkeyであり、ユーザー資産の秘密鍵を預かる仕組みではありません。build/sign/broadcastの署名工程は自社側で完結させられます。
スクリーニングは入金前と入金後のどちらで行うべきですか。
資金を入金・解放してよいかの判断はon-ramp/off-rampの境界でrisk-scoreを使って解放前に行い、口座に定着したあとのアクティビティはKYTで継続監視します。両者は目的が異なるため使い分ける前提で設計します。
チャージして、キーを取得し、リリース。
セルフサーブ。暗号資産またはカードで支払い。クレジットで従量課金——重いプリミティブは高く、単純なものは安価。
APIキーを取得