スケールするKYCレビューキューの設計

KYCレビューキューとは、機械だけでは判定しきれなかった本人確認のチェックを、人が確認するためのバックオフィスのワークフローです。申請の大半は自動で通過すべきで、キューは通過しなかった案件のために存在します。設計上の目標は、小さく保つこと、つまり本当に判断が分かれる案件だけを抱えることです。機械が判定すべき案件で埋まるキューは、統制ではなく、サインアップ数に比例して膨らむボトルネックだからです。キューを正しく設計すれば、バックオフィスは取引量ではなく例外の数に応じてスケールします。

意図的に小さく保つというこの一点が、以降のあらゆる設計判断を決めます。まず、それを可能にする振り分けから始めましょう。

目標はストレートスルー、キューは例外

ストレートスルー処理（STP）とは、申請が人の手を介さず最初から最後まで完了することです。書類の読み取り、本人照合、制裁リストおよびPEPスクリーニングのクリア、ライブネス確認の通過、判定の記録までが自動で行われます。これが一般的な経路であるべきで、この経路を通る申請の割合、つまりSTP率は、キューがスケールするかどうかを示す唯一の数字です。9割台が自動で完了するなら、人によるキューに流れ込むのは管理可能な少量です。半数がレビューに回るなら、成長に合わせてレビュアーを採用し続けることになります。キューはKYCを行う場所ではありません。自動化されたKYCが判断に自信を持てなかったことを認める場所です。STP率を上げれば、他の数字も自然に改善します。キューに入る案件が減り、待ち時間が短くなり、採用すべきレビュアーも減ります。ここは正面から改善する価値があります。クライアント側での書類撮影の精度向上、撮影前の明確な案内、慎重すぎるルールで正当な顧客が弾かれないようにする照合しきい値の調整などです。ここで1ポイント取り戻すたびに、誰かの午後を奪うはずだった案件が1件消えます。

キューに入る案件と、その理由

案件がレビューに回るのは、具体的で名指しできる理由があるからであり、その理由こそが案件が持つ最も重要な属性です。書類の写真がぼやけて読めない。身分証の氏名が申請書の氏名と一致しない。制裁リストやPEPのスクリーニングで、人が確認または棄却すべきヒットの可能性が出た。住所をどの情報源でも確認できない。ライブネス確認に失敗した、あるいは同じ顔や書類がすでに別の口座に存在する。これらはそれぞれ種類の異なる作業で、求められる判断も異なります。にもかかわらず、区別なく1つの山にまとめてしまうのが、レビューキューの最初の失敗です。しかも、同じ理由でも重みは大きく異なります。氏名の不一致は、結婚による改姓という何でもない差異かもしれませんし、なりすましの最初の兆候かもしれません。キューの役目は、その違いを見分けられる担当者に案件を回すことであり、慎重に検討すべき案件に拙速な判断を強いることではありません。

キューは1つでは足りない：理由別に分ける

キューが1つだけだと、すべてのレビュアーがゼネラリストであることを求められ、すべての案件が無関係な案件の後ろで待たされます。理由別に分ければ、この両方が解決します。制裁リストの該当可能性キューは、スクリーニングと処理判断の訓練を受けた担当者が扱います。書類品質キューは、経験の浅いレビュアーが数秒で片付けられる、素早い目視チェックです。重複口座キューは、不正調査にあたります。各セグメントには、それぞれ固有のルーティング、必要なスキル、サービスレベル目標を設定します。ぼやけた写真は数分で解決すべきですが、本物の制裁リストのヒットには、急がず慎重な処理が求められるからです。セグメント化によって、スループットと厳格さは、どちらかを犠牲にするのではなく両立します。

審査キューは、審査担当者を増やしても拡大できません。拡大の鍵は、そもそも審査が不要だった案件を正しく見極めること、そして審査が必要な案件を、理由ごとに仕分けた状態で届けることです。

理由必須・監査対象のアクション

審査担当者が下すすべての判断（承認、却下、エスカレーション、追加書類の依頼）には、理由の入力を必須とし、記録を残す必要があります。後から付け足す自由記述ではなく、アクションを実行した時点で、その理由を構造化された選択肢として記録します。これは形式主義ではありません。キューの判断を説明できる状態にするための仕組みです。規制当局や監査人、後任の審査担当者から、フラグが付いていたのになぜ承認したのかと問われたとき、答えとして示せるのは、担当者名、タイムスタンプ、そして記録された理由です。監査証跡は追記専用のため、判断を後からこっそり書き換えることはできません。訂正は既存の記録への上書きではなく、新しいエントリとして残します。当社のスタックでは、このキューと監査モデルは Protocore Center（/products/center）にあります。特権操作のすべてに理由が必須で、改ざんできないログに記録されるオペレーターコンソールです。

four-eyes が必要なケース

判断によっては、一人に委ねるには影響が大きすぎるものがあります。制裁リストへの該当の解除、高リスクプロファイルの承認、自動却下の覆しなどは、二人目の審査担当者による確認、つまりメーカー・チェッカー（four-eyes）を必須とすべきです。一人目が理由を添えて提案し、権限を持つ二人目が理由を添えて承認または却下します。両方の操作がログに残ります。これは審査担当者への不信ではありません。リスクの最も高い承認ほど一度のミスのコストが大きく、第二の目がその最も安価な保険になる、という考え方です。キューの設計では、これらのケースを理由に応じて自動的に二段階の処理へ振り分け、担当者の記憶に頼らないようにします。ただし二段階は影響の大きいケースに絞ってください。すべてに適用するとキュー全体のコストが倍になり、二人目の署名が形だけの承認印になってしまい、二重化の意味が静かに失われます。

件数に備える設計：滞留期間、優先度付け、SLA

増える一方のキューは、機能していないキューです。滞留を防ぐ圧力を設計に組み込みましょう。案件の滞留期間を可視化すれば、放置される案件はなくなります。セグメントごとにサービスレベル目標を設定すれば、数分単位のSLAを超過した不鮮明な写真の案件と、より長いSLAの範囲内にある制裁案件を、区別して扱えます。優先度付けは実際の選択です。古い順は公平でシンプルですが、想定される影響が最も大きい案件を先頭に置くリスク優先の方が適切な場合も多く、その際は滞留期間を同順位の判定に使い、低リスク案件が放置されずに処理されるようにします。審査担当者の画面には、一覧から選ばせるのではなく、振り分けと優先度付けが済んだ次の案件を表示します。担当者が選り好みするキューでは、厄介な案件が選ばれずに残るからです。滞留期間が見えないキューは、静かに腐っていきます。難しい案件は底に沈み、簡単な案件だけが上で回転し続けます。それを明らかにできる唯一の指標、つまり最も古い未処理案件の滞留期間は、顧客から苦情が来るまで誰も見ていない数字です。

キューの計測

設計が機能しているかどうかは、四つの数字でわかります。STP率は、人手を介さずに済んだ割合を示します。キューの深さとその推移は、処理が追いついているか遅れているかを示します。セグメントごとにSLAと照らして追うtime-to-decisionは、顧客のオンボーディング待ちが長すぎないかを示します。そして再オープン率、つまり後から覆された判断の割合は、審査担当者が正しく判断しているのか、単に速く判断しているだけなのかを示します。これらは互いにトレードオフの関係にあるため、あわせて見てください。再オープン率が上がるなかでtime-to-decisionだけを縮めたなら、ミスと引き換えに速度を買ったことになります。健全なキューとは、小さく、滞りなく流れ、正しく判断され、未処理の案件について正直なキューです。

人々が思い描くバックオフィスといえば、スタッフが部屋いっぱいに並んで申込書を入力し続ける光景でしょう。それは、自動化で処理できる範囲が小さく、キューが区別のない一山になっているときの姿です。スケールするバックオフィスはその逆です。ほとんどの申込みは人の手に渡らず、渡る案件は理由と優先度で仕分けられて届きます。すべての操作は理由とともに追記専用ログに残り、four-eyes が必要な判断だけを守ります。キューは例外のために作れば、成長しても小さく保てます。KYC を行う場所として作れば、申込みが増えるたびに膨らみ続けます。