金融サービス

inTheEU Assist · ケーススタディ · 2026 年 7 月

トランザクション レビュー、AML スクリーニング、およびエスカレーション チェーンはすべて同じ要件を共有しています。つまり、決定が正しかっただけでなく、その後、機関自身のログに依存せずに独立して再構築できることです。このページは、そのようなワークフローがどのように計画され、inTheEU Assist で実行されるかを説明するものであり、完了した展開の記録ではありません。

ワークフローの構成方法

提案された複数ステップのアクション、トランザクションのレビュー、フラグ付きパターン、エスカレーションは、一連の段階として計画されます。シーケンス全体は実行前にハッシュ化されるため、承認者がレビューする計画がまさに実行される計画になります。人間に示されたものとシステムが実際に実行したものとの間にギャップはありません。

リスクを伴うとフラグが立てられたステージ (エスカレーション、顧客向けの出力、最終決定) には、最初の計画レベルの承認とは別に、独立した 2 回目の承認が行われます。ワークフローに対する一般的な承認は、実際に重要な点での特定の承認に代わるものではありません。

人間の承認が置かれる場所

顧客、取引、または規制当局への申告に影響を与える可能性のあるすべての段階では、続行する前に明示的な署名付き承認が必要になります。何がリスクシグナルを構成するかについては、コンプライアンスチームとクオンツチームが引き続き権限を持ちます。プラットフォームの役割は、決定が完了したら、その決定とその根拠が記録されるだけでなく証明可能であることを確認することです。

これが今日のベースとなっているものとベースになっていないもの

2 層の承認構造、計画レベルのハッシュ、および各実行ステップの背後にある署名付きのオフライン検証可能な監査証跡は、プラットフォームの機能部分です。これに含まれないもの: 事前に構築された AML または不正検出モデル。金融機関自身のコンプライアンスチームとクオンツチームが、リスクシグナルを定義するロジックを提供します。プラットフォームは、その下に管理された実行層と監査層を提供します。

この機能セットの基礎となるアーキテクチャの一部は、現在進行中のファイルに文書化されています。このページでは、実装仕様ではなく、パイロットの計画に適したレベルでプラットフォームが何を行うように設計されているかについて説明します。