プラットフォームアーキテクチャ、システム統合、検知モデルのガバナンス、審査対応の組み合わせが多いです。技術的には、Actimize、Oracle FCCMなどのシステムを含む、コンプライアンスプログラムが実際に動くフレームワークとデータアーキテクチャを整えること。規制対応の面では、すべてが順調なときだけでなく、監査や当局の精査を受けたときにも統制が機能するようにすることです。
金融犯罪アドバイザリー
金融犯罪テクノロジープラットフォームの設計と運用を担っています。コンプライアンスの課題は、その仕事の一部です。
金融機関のトランザクション監視、制裁スクリーニング、ケース管理、そしてそれらを結ぶデータ基盤 — こうした金融犯罪テクノロジープラットフォームの設計とガバナンスを担っています。マルチベンダーエコシステムの設計、プラットフォームの統合・整理、検知モデルのガバナンス、そして規制当局や内部監査が実際に求めるトレーサビリティの構築が主な仕事です。
- AML & トランザクション監視
- 不正検知 & FRAML
- 制裁 & スクリーニング
- モデル検証
- デジタル資産コンプライアンス
- 金融犯罪における AI 活用
- OCC / BSA / FinCEN
- NYDFS Part 504
- OFAC / SDN
- FATF Travel Rule
- OCC 2011-12(モデルリスク管理)
金融犯罪の分野に入る前は、開発者とDBAとして働いていました。その経歴が、テーブルでできることを変えます。誤検知が多い、モデルが検証を通らない、スクリーニングシステムが見落としを起こしている — こうした問題の原因はたいていポリシーではなく、データやシステム設計にあります。こうしたシステムを実際に構築・運用してきたからこそ、問題の根本に到達できます。内側がどうなっているか、知っています。
ここに至るまでのこと。
ブラジル南部のカシアス・ド・スル出身です。キャリアは開発者からスタートし、Oracle Forms、Reports、Designer、DBA業務、VB開発を経て、チームリーダーを担いました。その後、金融犯罪の世界に入り、それ以来ずっとこの領域で働いています。最近では、資金調達・財務システムを含む幅広いコンプライアンステクノロジーにも携わっています。
開発者としての経歴は、単なる前職ではありません。法務や監査出身の専門家とは異なる視点でAMLや不正の問題にアプローチできる理由がそこにあります。データエンジニアとセグメンテーションロジックを見直し、アラート生成の仕組みを再設計し、クオンツチームとモデル検証のトレーサビリティの欠如に向き合い、コンプライアンス担当者とシステムアーキテクトがシステムの挙動について意見が合わない場面に何度も立ち会ってきました。その両側の議論を理解しています。
これまで、米国、カナダ、欧州、中東、アジア太平洋、ラテンアメリカの各地域で業務に携わってきました。それぞれ規制当局も、リスクの特性も、プログラムの成熟度も大きく異なります。その幅広い経験が、実際に防御可能なプログラムと、内部レビューを通過するだけのプログラムの違いを見極める力になっています。
現在の中心はプラットフォームアーキテクチャ — 金融犯罪システムがスタック全体でどのように設計・接続・統治されるか、という問いです。後から修正しにくい部分に取り組むことが多いです。検知システムと財務システム間のデータ統合、技術的負債を蓄積するベンダー選定の判断、そしてモデル検証と審査対応を場当たり的でなく実務的に機能させるガバナンス層です。このサイトは私自身の考えをもとにしています。英語、ポルトガル語、スペイン語を話します。
仕事以外では、子供2人、猫4匹、犬2匹、そして同じくカシアス・ド・スル出身の妻とともに、ノースカロライナ州シャーロット近郊のコンコードに暮らしています。
最も貢献できる領域。
AML & トランザクション監視
トランザクション監視とケース管理プラットフォームの設計と安定化。アラートロジック、セグメンテーション、チューニング。SAR品質とエスカレーション経路の設計。重複するシステムの統合や、スケールでのアラート生成を不安定にするデータ統合の問題修正が多くを占めます。チューニングの問題に見えて、実はアーキテクチャの問題であるケースです。
不正検知 & FRAML 統合
不正リスクプログラムの設計、手口類型のカバレッジ、そしてAMLと不正検知がデータ・業務プロセス・調査基盤を共有すべきかという構造的な問い。多くの機関が両者を分離したままにしており、それがカバレッジの空白と業務上の非効率を招いています。
制裁 & スクリーニング
スクリーニング設計、ウォッチリストの整備と更新、名寄せの設定、誤検知管理、コルレス銀行取引やデジタル資産の決済フローへの対応。OFAC SDN、国連、EU、OFSIおよび各管轄固有のリスト管理を含みます。
モデル検証 & AI
モデルリスクガバナンスフレームワークの設計、検知モデル・スコアリングロジック・閾値設定の独立したレビュー。検証を追跡可能・再現可能・防御可能にするインフラと文書の構築 — 形式的なコンプライアンスにとどまらない実質的な対応。説明可能性と監査対応が審査要件であるAI環境向けのガバナンス設計を含みます。
デジタル資産リスク
クリプトネイティブ機関および間接的なエクスポージャーを持つ銀行向けのコンプライアンス設計。ブロックチェーンアナリティクスの導入、Travel RuleおよびTRISAの実装、VASPカウンターパーティリスク、オンチェーン活動の制裁スクリーニング。現在の審査官が実際に求めていることを起点に設計します。
KYC / CDD / EDD
オンボーディング管理、顧客リスク評価の手法、実質的支配者の特定、強化デューデリジェンスの業務フロー、そしてそれを支えるデータ基盤。維持も説明もできないリスク格付けモデルは負債です。多くの問題はポリシーではなく、データと業務設計に起因しています。
繰り返し書いているテーマは、現場でも繰り返し出てくるからです。
規制対象企業でファイナンス変革が失敗する理由は、ある程度決まっています。
問題はテクノロジーでも志の高さでもありません。変革プログラムが、コンプライアンス・リスク・規制上の制約と、置き換えようとしているシステムとの相互作用を考慮せずに設計されていることにあります。
ステーブルコインは、コンプライアンスプログラムが追いつくのを待ってくれません。
ステーブルコインはすでに、規制対象機関の決済フローや顧客取引の中を動いています。その機関がステーブルコインに関するポリシーを持っているかどうかに関係なく。
AIにはデータの問題がある。そしてほとんどの人は問題の場所を間違えている。
問題はモデルではありません。そこに投入されるデータにあります。そのデータを形作った組織的な意思決定は、学習が走るずっと前に行われています。
あなたの銀行は暗号資産を扱っていない。それでも、暗号資産はあなたの銀行に影響を与えているかもしれない。
暗号資産へのエクスポージャーは、顧客の取引行動、送金パターン、コルレス関係を通じて生じます。多くの場合、参入を意識する前から始まっています。
モデル検証こそ、コンプライアンスプログラムが最もリスクにさらされやすい領域です。
モデルが誤っているからではありません。審査の場で、意思決定の根拠を説明できず、出力を再現できず、バージョン間の変更を示せないことが問題になります。
金融犯罪へのAI導入は、テクノロジーの問題より前に、ガバナンスの問題です。
本当に難しいのはここです。閾値の変更を誰が承認するのか、どう記録に残すのか、担当者がモデルのスコアに納得しない場合どう対処するのか。
まずは短いメッセージをどうぞ。
AML、制裁、モデルリスク、不正検知、デジタル資産に関する課題について、セカンドオピニオンや方針のご相談があれば、状況を数行お知らせいただければ十分です。
メッセージは直接私に届きます。このページにメールアドレスは掲載していません。