Amazon Web Services ブログ

Amazon EKS とグラフデータベースを利用した金融犯罪の発見

この記事は、2022 年 2 月 1 日に Severin Gassauer-Fleissner、Zahi Ben Shabat によって投稿された「 Financial Crime Discovery using Amazon EKS and Graph Databases 」を翻訳したものです。

金融データの増加により、金融犯罪の発見と解決が課題となっています。取引決済データを構造化されたテーブル形式で保存することは、検索、フィルタリング、計算に便利ですが、取引データを表現する方法としては必ずしも理想的ではありません。例えば、企業 A企業 B の間に疑わしい金銭的な関係があるかどうかを判断する場合、テーブルで可視化することは困難です。テーブルを使用する場合、企業 A から可能なすべての取引について SQL 結合を行う必要があります。そして、企業 B との関係を見つけるまで、このプロセスを繰り返さなければなりません。さらに、リレーショナルデータベースマネジメントシステム (RDBMS) 上で実行するには難しいクエリもあります。例えば、どの口座が他の口座から最低金額の 10,000,000 USD を受け取ったのかを発見するには、相当な時間が掛かります。

Amazon Neptune などのグラフデータベースは、データを横断して同時に計算できるため、クエリを実行する際にとても便利です。グラフはネットワーク上でつながった複数の取引や関係者を表し、パターンやつながりのある連鎖を発見できます。疑わしい取引のパターンを発見できるため、アンチマネーロンダリング (AML) アプリケーションで使用されることが一般的です。

私たちは、複雑なクエリを高速に実行するために、高いメモリと CPU 構成を効果的に使用し、数百万件の取引を処理できる拡張性のあるソリューションを必要としていました。グラフデータベースが、金融犯罪の発見に役立つことを示すお客様向けデモンストレーションの一環として、ソリューションをテストするための大規模なデータセットも用意しました。私たちは、グラフデータベースである Amazon Neptune と Amazon Elastic Kubernetes Service (EKS) を使って、大量の取引データから数分で疑わしい金銭的な連鎖を検索することができました。

金融犯罪発見ソリューションのコンセプトの概要

Figure 1. Workflow for financial crime discovery

図1. 金融犯罪発見のためのワークフロー

まず、取引の推論を行うことができるルールエンジンを見つける必要がありました。このエンジンは、データに対してさまざまなルールを処理できること、効率的であること、そして拡張性があることが必要でした。次に、データをソリューションに簡単に取り込める必要がありました。データを用意した後は、推論を開始するためのタスクを起動する必要がありました。最後に、さらなる分析と永続化のために、図1 に示すような、結果を保存する場所が必要でした。

AWS クラウドを利用したグラフデータベースのスケールアップ

図2 に示すように、複数の AWS サービスを使用して、完全に自動化されたエンドツーエンドのバッチベースのトランザクションプロセスを作成しました。私たちは、Oxford Semantic Technologies が開発した AWS Marketplace 製品である RDFox を使用しました。RDFox は、高性能のインメモリグラフデータベースとセマンティック推論ツールです。RDFox をオーケストレーションするために、Amazon EKS で Cluster Autoscaler を使用し、RDFox コンテナをインスタンス化するためのクラスターを起動させました。Amazon EKS は、差分推論ジョブ用に複数のコンテナを起動し、ジョブが終了するとリソースをリサイクルします。また、分析と長期保存のために、最大 64TiB まで結果を保存できる Amazon マネージド分散グラフデータベースの Amazon Neptune を使用しました。

データは Amazon S3 バケットに保存することによって、大規模なデータセットを処理する効率的な方法を実現します。

Figure 2. Architecture diagram for financial crime discovery

図2. 金融犯罪発見のためのアーキテクチャ図

金融犯罪のルール

グラフの威力は、関係や金銭的取引に現れる金融犯罪を発見する際に発揮されます。これを実証するために、2 つのシナリオを検出する 2 つのルールを示します。

  1. 疑わしい 2 人の関係者 XY がいるとき、その間に取引関係があるかどうかを調べ、もしあれば、それらをつなぐ連鎖を付与します。これは、金融機関が検出しなければならない一般的なシナリオです。
  2. 疑わしい取引を特定する連鎖がある場合、受取人が受け取った最低金額が閾値 Z USD を超えているかどうかを調べます。

データの生成

私たちは、テスト用のデータを生成するため、Python で書かれた合成データジェネレーターを使用しました (参考文献の GitHub リポジトリを参照) 。このジェネレーターは、関係者と取引という 2 つのグラフ要素を作成しました。すべての取引はランダムな 2 人の関係者でペアになっており、この反復プロセスにより、関係者取引をつなげたネットワークが作成されます。

先述のビジネスシナリオをシミュレートするため、「疑わしい関係者」のタグ付けの割合を少なくした (0.01%) 関係者のデータセットを作成しました。これらの関係者には、入金と出金の両方の取引があることに留意してください。他の疑わしい関係者と接触することによって、連鎖が成立する場合もあります。この方法により、疑わしい連鎖を操作することなく、シミュレーションデータを得ることができます。
このソリューションで使用されるテスト用のデータセットは、百万の取引と数千の関係者から構成されています。
データ生成の詳細については、GitHub: Transaction Chains Data Generator をご参照ください。

財務調査担当者のワークフローのウォークスルー

本ソリューションを導入すると、以下のような流れで調査担当者を支援することができます。

  1. 調査担当者は、取引と関係者のデータ (nt triples) を、入力バケット内のサブディレクトリに配置します。通常、サブディレクトリには日付または日付の範囲を指定することができます。さらに、データに対して処理しなければならない特定のルール (dlog ファイル) およびクエリ (rq ファイル) をアップロードします。
  2. データの準備ができたら、調査担当者はジョブの定義ファイル (simple JSON の参考文献のセクションを参照) をアップロードします。これには、ジョブが必要とするリソース (CPUとメモリ) 、およびジョブのその他の設定が記述されています。
  3. ジョブ定義がバケットのサブディレクトリにアップロードされると、ジョブが自動的に開始されます。Kubernetes のスケジューラーは、RDFox ポッドを起動するために十分なリソースを割り当てます。その後、ポッド内のコンテナがロードされ、処理を行い、クエリの結果を出力バケットにアップロードします。
  4. データが出力バケットに保存されると、AWS Lambda 関数が実行されます。これは Amazon Neptune Bulk Loader を呼び出し、Neptune クラスターに結果を非同期で並列にロードします。
  5. ロードが完了すると、ジョブが完了し、結果が表示できるようになったことがメールで調査担当者に通知されます。

さらに

  • 調査担当者は複数のルールやクエリをアップロードすることができ、それらはすべて自動的に処理されます。
  • 調査担当者は、異なるデータか同じデータを使用して、複数のジョブを起動し、異なるルールとクエリを同時に起動できます。
  • すべてのジョブの出力は、出力バケット内の一意のジョブ ID サブディレクトリに保存されます。

あなたのアカウントでソリューションを作成するには、こちらの GitHub リポジトリの説明に従ってください。

前提条件

このチュートリアルでは、以下の前提条件を満たしている必要があります。

ルール

説明した 2 つのシナリオを用意するために、2 つの実体化したルールセットを作成します。

1. detect-suspicious-parties-pair.dlog

この最初のルールセットの目的は、疑わしい 2 人の関係者の間に、存在する可能性がある連鎖を検出することです。これらの連鎖の目的は、疑わしい送金人と受取人間の送金を含むすべての可能な関係を表すことです。これには、疑わしい関係者以外も連鎖に含まれます。このルールでは、これらの連鎖に「SuspiciousChain」(疑わしい連鎖) フラグを付けます。

2. detect-chains-exceed-100-dollars.dlog

このルールセットは、最初のルールセットによって識別された連鎖にタグを付けるためのものです。また、受取人に渡される最低金額の 100 USD が含まれています。異なるコンプライアンス要件を確認するために、この金額を変更することができます。これらの連鎖に「HighValueChain」(高価値連鎖) というタグを付けます。

ジョブを実行して結果を確認する

これで、与えられたデータ、ルール、そして 2 つの追加クエリ (「SuspiciousChain」(疑わしい連鎖) と「HighValueChain」(高価値連鎖) をそれぞれ抽出する) を用いて、ジョブを実行することができます。クエリの結果は自動的に Amazon Neptune にロードされて、永続的に保存され、さらなる分析に利用できるようになります。

では、その結果を見てみましょう。以下のクエリは、RDFox コンソールまたは Amazon Neptune に対して実行することができます。

可視化

PREFIX : <http://oxfordsemantic.tech/transactions/entities#>

PREFIX prop: <http://oxfordsemantic.tech/transactions/properties#>

PREFIX type: <http://oxfordsemantic.tech/transactions/classes#>

PREFIX tt: <http://oxfordsemantic.tech/transactions/tupletables#>

SELECT ?S ?P ?O WHERE {

            ?S a type:SuspiciousChain .

            ?S ?P ?O .

}

Figure 3. Visualizing suspicious chains

図3. 疑わしい連鎖の可視化

ワオ ! 図 3 は一見複雑に見えますが、これは、疑わしい関係者と別の疑わしい関係者のすべてのペアを可視化しているためです。このクエリをフィルタリングして、受取人に最低 100 USD を超える、ある特定の連鎖だけを調べてみましょう。以下のクエリは、RDFox コンソールまたは Amazon Neptune に対して実行することができます。

PREFIX : <http://oxfordsemantic.tech/transactions/entities#>
PREFIX prop: <http://oxfordsemantic.tech/transactions/properties#>
PREFIX type: <http://oxfordsemantic.tech/transactions/classes#>
PREFIX tt: <http://oxfordsemantic.tech/transactions/tupletables#>

SELECT * WHERE {
?S ?P ?O
{
SELECT ?S WHERE {
?S a type:HighValueChain .

} Limit 1

}

Figure 4. Visualizing a particular chain

図4. 特定の連鎖の可視化

図 4 では、疑わしい連鎖の送金人である Allison が Troy に送金していることがわかります。Troy は疑わしい関係者ではありませんが、それを Karina に送金しました。Karina は疑わしい受取人です。また、Karina が受け取った金額や、この場合の連鎖の長さが 2 であることなどの追加情報も確認できます。

私たちのテストでは、5 千万人の関係者との 5 億件の取引を 2 時間未満で処理できました。しかも、同じようなハードウェアを固定で使い続けた場合と比較して、大幅な低コストにて実現しました。

クリーンアップ

Terraform のクリーンアップ手順に従います。

まとめ

グラフデータベースは、複雑な金銭的な関係に対して推論を適用するための強力なツールです。Amazon Web Services と RDFox エンジンの組み合わせは、動的な Kubernetes Cluster Autoscaler のおかげで、自動化、拡張性、およびコスト効率の高い結果をもたらします。お客様はこのソリューションを利用し、金融取引に関する実験や推論ができるツールを調査担当者に提供できます。このソリューションは、プロセスを簡素化し、複雑な大規模データのコレクションで異なるルールやクエリを簡単に試すことができます。

このブログ記事は、Oxford Semantic で書かれています。

Oxford Semantic Logo

参考文献

ソリューション

更に詳しく

RDFox

その他


Severin Gassauer-Fleissner

Severin Gassauer-Fleissner

Severin “Sev” Gassauer-Fleissner は、Amazon Web Services の Principal Solutions Architect で、APJ の FSI Prototyping and Cloud Engineering (PACE) リーダーを務めています。彼のチームは、お客様が AWS 上でプロトタイプを構築し、アーキテクチャの実証が行えるよう支援しています。Sev は、分散システムに情熱を傾け、金融機関のお客様のための物作りや、物事の仕組みを理解することに取り組んでいます。余暇には、テクノロジーについてあれこれ考えたり、シンガポールでサイクリングをしたり、ファンタジー小説を読んだりしています。

Zahi Ben Shabat

Zahi Ben Shabat

Zahi Ben Shabat は AWS の Sr. Prototype Architect で、プロトタイプを構築することによって障害を取り除き、お客様のクラウドジャーニーを加速させるための支援をしています。彼は、10 年近く金融機関のお客様と仕事をしてきました。自由な時間には、アウトドア、音楽演奏、水泳を楽しんでいます。

翻訳は Senior Solutions Architect の 立花 正英 が担当しました。原文はこちらです。