株式会社メルペイのAML/CFTチームでバックエンドエンジニアを努めているyagi5です。この記事はMERPAY TECH OPENNESS MONTHの6日目の記事です。

私たちメルペイが目指すのは、単なる決済手段を提供することだけではありません。
「信用を創造して、なめらかな社会を創る」プラットフォームになることです。
そのためには、お客様がメルペイ、メルカリを「あんしん・あんぜん」に利用できなければなりません。

メルペイにおいてその役目を担っているのが、筆者の所属する「AML/CFTチーム」です。
この記事では、読者の皆さんには馴染みが薄いかもしれない「AML/CFT」について紹介すると共に、私たちが日々取り組んでいる、メルペイのあんしん・あんぜんを支える技術について書きたいと思います。
最後までお読みいただければ幸いです。

AML/CFTとはなにか

AML/CFTとは「Anti-Money Laundering/Counter Financing of Terrorism」(マネー・ローンダリングおよびテロ資金供与防止対策) のイニシャルです。
組織犯罪の撲滅やテロ組織への資金供与を絶つための取り組みであり、日本以外の各国でも推進されています。
特に日本では、顧客と取引を行う際の「本人確認」(「Know Your Customer」、KYC) や、顧客との取引が犯罪による収益からくるもの (「疑わしい取引」と呼称しています) であった場合に、当局に届け出を行うことなどが法令により義務付けられています。

メルペイのミッションは、「信用を創造して、なめらかな社会を創る」ことです。
すなわち、社会インフラの一端を担う存在であるメルペイにとって、不正行為を未然に防ぐ仕組みを構築し、お客様にあんしん・あんぜんにご利用いただけることはなにより大切なことです。
そのために、AML/CFTシステムは高い信頼性を持って稼働し続ける必要があります。

メルペイのAML/CFTシステムを支える技術

お客様にあんしん・あんぜんなプラットフォームを提供するにあたり、AML/CFTシステムはメルペイを利用して行われる膨大な量のトランザクションを監視し、疑わしい取引を速やかに検知する必要があります。

メルペイのシステムはメルカリと同様に分散化されており、各ドメインごとにオーナーがいる、いわゆるマイクロサービスアーキテクチャになっています。
AML/CFTシステムが疑わしい取引を検知するために必要とするデータは多岐に渡ります。私たちはそれらを効率よく、かつ抜けもれなく収集し、「疑わしい」かどうかを判定しなければなりません。

そもそも、「任意の取引について、それが疑わしい取引である」という状態を、システムではどのように表現し、そして検知できるのでしょうか？

これを実現するためには、「疑わしい取引である」という状況を、「ルール」として表現するクエリを書き、そのクエリを取引情報を保持するデータベースに対して実行するというアプローチが考えられます。

具体的な例を挙げて考えてみましょう。
例えば、「個人口座から1日に1,000,000円の送金が行われた場合に検出する」といった状況を「疑わしい」と定義しましょう。 (これは私がたった今思いついた例にすぎません。)
試しに、このルールを表現するクエリを書いてみましょう。
馴染みの深いSQLを使うとしたら、以下のように書くことができるでしょう。

SELECT
*
FROM
transfer_histories
WHERE
SUM(amount) >= 1000000
GROUP BY
user_id, date;

私たちはこのクエリを定期的に実行することで、「疑わしい取引」を検出することができます！

私たちはこれをもっと洗練されたやり方で実現するために、Rule engineが利用できないかを検討しました。
Rule engineとは、DSL (Domain Specific Language) などで「ルール」を書き、CEP (Complex Event Processing) を実現するためのソフトウェアです。

Complex Event Processingとはなんでしょうか？イベント生成にはいくつかのパターンがありますが、CEPにはいくつかの特徴があります。
Wikipediaには以下のような記載があります。

Complex event processing, or CEP, is event processing that combines data from multiple sources to infer events or patterns that suggest more complicated circumstances.

CEPとは、複数のデータソースを元に、より複雑な状況を示すイベントを生成するパターンです。日本語では「複合イベント処理」などと訳されます。
パブリッシュ・サブスクライブモデルのようなシンプルなイベントドリブンアーキテクチャと比較して、より複雑な状況を表現することを目的としています。

ちなみに、CEPはその用途からしばしばデータウェアハウスの代替であるかのように言われます。
しかし、CEPはあくまでストリームデータを使って (ニア) リアルタイムにデータ分析を行うものであるのに対し、
データウェアハウスは時系列に蓄積された比較的大量のデータを分析するものである、という違いがあります。

Rule Engineは、ビジネスエンティティやリレーションを表現するクエリを「ルール」とし、ルールに該当したデータをイベントとして (CEPのアプローチで) 扱う機能を実現します。

前述の通り、メルペイのシステムは分散しているため、必要とするデータソースも複数存在します。
複数のマイクロサービスからデータを収集し、「疑わしい」という状態を表現するルールを書き、ルールに該当した場合は適切なアクション (必要な場合当局に報告など) を取る、というAML/CFTシステムの要件に最適なソフトウェアと言えるのではないでしょうか！

注意深く慎重な検討の結果、私たちはこれらを実現するためのソフトウェアとして、Splunkを採用することを決めました。

ここからは、私たちがSplunkをどのようにAML/CFTシステムに活用しているかをお話します。

Splunkの活用

私たちはRule engineにSplunkを採用しました。
その理由はいくつかあります。
まず、Splunkが既にAML/CFTシステムでの採用実績があったことが挙げられます。
Splunkは公式に、Fraud detectionのユースケースを紹介しており、ルールベースでのトランザクション監視はAML/CFT用途にうってつけです。

また、Splunkは非常に強力なソフトウェアで、各パブリッククラウドとの連携機能がネイティブに用意されています。
例えば、GCPが提供するCloud Pub/Subや、AWSが提供するAmazon Kinesis Data Firehoseとの連携が可能です。
(実際のところ、Amazon Kinesis Data FirehoseにはそのためのAPIがあるし、Terraformを使ってSplunk delivery configurationをセットアップすることもできます。)

私たちはAWS上に、SplunkとSplunkにデータを集めるためのストリーミングデータデリバリーストリームを用意し、大量のデータをそこへ収集しています。
Splunkは、AML/CFTシステムの中核を担うソフトウェアであると言えます。

私たちは様々な理由で、SplunkをAWSのEC2上にホストしています。
したがって、ソフトウェアエンジニアはSplunkの運用だけでなく、クラスタの運用のための幅広い知識を必要とします。

Splunkのビジネス活用

私たちはSplunkをRule engine以外の用途にも利用しています。
Splunkには、抜群に便利なダッシュボード機能がありますから、たとえば、メルペイの決済の情報 (件数や、位置情報を地図上に表示することも可能です！) をダッシュボード化して (言うまでもなく、個人情報等のセンシティブな情報に対する権限は適切に管理されていますが) 、ビジネスに活用する取り組みも行っています。
私たちのSplunkを、メルペイを支えるデータプラットフォームに成長させたいと考えています。

最後に

AML/CFTについての簡単な紹介、そしてAML/CFTチームが取り組んでいる技術について書きました。
ただし、実際のところこれらはまだ私たちの仕事の一部に過ぎません。実際のところ、この記事ではTransaction Monitoringしか説明していません！
私たちのAML/CFTシステムが担う機能はまだ他にも存在します。

私たちが目指しているのは、「世界で一番優秀なAML/CFTシステムを構築する」ことです。
そのためには、まだまだやりたいことがあり、仲間を増やす必要があります。

AML/CFTチームでは共にメルペイのあんしん・あんぜんを支えるAML/CFTシステムの構築を行うソフトウェアエンジニアを大募集しています。
この記事を読んで興味を持った方は、ただいま開催中のカジュアル面談オープンドアに参加してください！
Tech LeadもしくはEngineering Managerと、もっと詳しい話をすることができます。

採用選考を検討できる方は、こちらのジョブディスクリプションをご覧ください。

最後までお読みいただきありがとうございました。
MERPAY TECH OPENNESS MONTH の 7 日目の記事は @hatappi による「AMLにおける各MSのデータをSplunkに集約して活用(仮)」です。
お楽しみに！