規則を管理する

Microsoft Dynamics 365 Fraud Protection を使用すると、Fraud Protection の最先端の人工知能 (AI) モデルが生成するスコアと、要求ペイロードからの追加パラメーターを使用するルールを柔軟に作成できます。 これらの入力に基づいて、ルールは評価を決定 (承認、却下、レビュー、チャレンジなど) に変換できます。

Fraud Protection インスタンスに複数の環境がある場合は、環境スイッチャーを使用して特定の環境のルールを管理できます。 環境に親環境がある場合は、最上位の親環境のルールが最初に評価されます。 最上位の親環境のルール設定が[決定されるまで一致するすべてのルールを実行する]に 設定されている場合、第 2 レベルの親環境のルールは次に評価されます。 このプロセスは、環境のルール設定が [最初に一致するルールのみを実行する] に設定されていない限り、または親環境と現在の環境のすべてのルールが評価されるまで続行されます。

ルールの定義: クイック スタート ガイド

規則は句で構成され、RETURN および WHEN キーワード (keyword)によって定義されます。 これらは、次の基本的な構造を持ちます。

RETURN <decision>
WHEN <condition>

RETURN ステートメントは、WHEN ステートメントが True に評価された場合にのみ実行されます。 RETURN ステートメントはルールの実行を終了し、有効な意思決定機能 (Approve、Reject、Challenge、Review) を指定する必要があります。 各デシジョン関数は省略可能なパラメーターを受け取り、決定の理由を表すこともできます。 詳細については、デシジョン関数を参照してください。

決定に加えて、RETURN ステートメントを使用して、API 応答またはイベント トレースにデータを書き込むこともできます。 詳細については、「観測関数」を参照してください。

WHEN ステートメントは、RETURN ステートメントが実行されるかどうかを判断するブール条件を指定します。

WHEN ステートメントでは、次のいずれかの項目を使用できます。

• 評価の API 要求で送信されるすべての属性 (カスタム データを含む)。 これらの属性には、@ 演算子を使用してアクセスできます。 たとえば、@"user.userId" のようにします。
• Fraud Protection の人工知能モデルから生成されるスコア。 たとえば、@"riskscore" のようにします。
• 不正アクセス防止にアップロードしたリスト。 リストをアップロードする方法の詳細については、「リストの管理」を参照してください。 ルールでこれらのリストを参照する方法の詳細については、「ルールでのリストの使用」を参照してください。
• 不正アクセス防止で定義した速度。 詳細については、「速度チェックの実行」を参照してください。
• 不正アクセス防止で作成した外部呼び出し。 詳細については、「外部呼び出し」を参照してください。
• 不正アクセス防止で作成した関数。 詳細については、「関数」を参照してください。

式は比較演算子 (==、!=、、<、など) を使用して比較でき、>(> や (>) や (||) などの論理演算子を使用して組み合わせることができます。

ルールの構文の詳細については、言語リファレンス ガイドを参照してください。

ビジュアル ビュー

ビジュアル モードを使用して、要求ペイロードの属性を使用してルールをすばやく簡単に書き込みます。

1. ビジュアル ルールを作成するには、[+ 新しい句] を選択 します。
2. 句名の横にある [ビジュアル ビュー] を選択します。
3. 句に複数のフィルターを追加し、ドロップダウン メニューから属性を選択できます。
4. コード ビューに戻り、不正アクセス クエリ言語のルールを表示および編集します。 コード ビューでルールを編集した後は、Visual View に戻ることはできません。

次の図は、ルールの ビジュアル ビュー と、ビューを 変更するために選択できる [コード ビュー ] ボタンを示しています。

次の図は、ルールの コード ビュー と、ビューを 変更するために選択できる [ビジュアル ビュー ] ボタンを示しています。

ルールの例

RETURN Reject("high score")
WHEN @"riskScore" > 900

RETURN Review("medium score")
WHEN @"riskScore" <= 900 and @"riskScore" > 400

RETURN Approve(), Other(ip=@"device.ipAddress")
WHEN @"user.countryRegion" == "US"

RETURN Reject("user on block list")
WHEN ContainsKey("Email Block List", "Emails", @"user.email")

RETURN Review()
WHEN @"user.email".EndsWith(“@contoso.com”)

[ルール] タブ

カスタム ルールを作成し、[ルール] タブで既存のルールを管理できます。

• 購入に関連するルールを作成および管理するには、[購入] を選択し、[ルール] タブを選択します。
• アカウントに関連するルールを作成および管理するには、[アカウントの作成] または [アカウント ログイン] を選択し、[ルール] タブを選択します。
• カスタム評価に関連するルールを作成および管理するには、[カスタム評価] を選択し、カスタム評価を選択して、[ルール] タブを選択します。

[ ルール ] タブには、評価の種類に対して構成されているルールの一覧が表示されます。 これらのルールは、発行済みルールと下書きという 2 つのセクションに分かれています。 下書きの詳細については、この記事の後半の 「下書き 」セクションを参照してください。

ルールまたは下書きごとに、次の情報を表示できます。

• 名前
• 作成した条件
• 状態: アクティブまたは非アクティブ

また、各ルールのタイルを選択して展開し、追加情報を表示することもできます。 次に例をいくつか示します。

• 説明
• ルール内の句の数
• ルールを最後に更新したユーザー
• ルールが最後に更新されたとき

Note

[ルール] タブでは、発行済みのルールが実行順に一覧表示されます。

ルールの設定

特定の評価の [ルール] タブでルール 設定にアクセスできます。 そこで、ルールの評価動作とサンプル ペイロードを変更できます。 これらの変更は、編集中の評価に対してのみルールに適用されます。

ルールの評価動作

ルールの評価方法を更新できます。 [最初に一致するルールを実行する] を選択した場合、トランザクションごとに評価されるルールは 1 つだけです。 そのルールが決定を返さない場合、それ以上のルールは評価されません。既定の承認の決定が返されます。 [決定が行われるまで一致するすべてのルールを実行する] を選択すると、1 つのトランザクションに対して複数のルールを評価できます。 評価される最初のルールが決定を返さない場合、後続の各照合ルールは、決定が返されるまで評価されます。

サンプル ペイロード

[ペイロードの設定] ウィンドウで、評価の種類のサンプル ペイロードを定義できます。 サンプル ペイロードは、評価の要求 API で送信され、ルールで使用できるフィールドの例を含むものです。

API 要求では、評価スキーマから省略可能なフィールドを送信しないことを選択できます。 または、追加のユーザー設定フィールドを送信することもできます。 どちらの場合も、[ペイロード設定] ウィンドウに表示されるペイロード サンプルを更新して、送信する特定のフィールドが反映されるようにしてください。

このペイロード サンプルは、評価用に新しいルールが作成されるたびに表示されます (この記事の後半の ペイロードサンプル セクションを参照してください)。 行った変更は、その時点以降に作成したルールにのみ適用されます。

自分または他のユーザーがペイロード サンプルに加えたすべての変更を元に戻し、システムの既定のペイロード サンプルに戻すには、[元に戻す] を選択します。

ルールのコンポーネント

ルールは、次のコンポーネントで構成されます。

• 規則の目的を説明する名前と説明
• ルールの現在 の状態 : アクティブ または 非アクティブ
• ルールの記述と評価に役立つフィールドのサンプル
• イベントを自動的に承認、拒否、チャレンジ、またはレビューするロジックを構築するのに役立つコンポーネント:
  • 条件
  • 次の 1 つ以上の種類の 句:
    • すべてのスコア付け句の前
    • ボットスコアリング後の句
    • リスクスコアリング後の句

発行されたルールには、下書きバージョンを含めることもできます。

名前と説明

ルールを作成するときに、自分とチームがルールを簡単に識別できるように、名前と説明を追加できます。 ルール名は一意である必要があり、大文字と小文字は区別されません。

状態

最初にルールを作成すると、状態は発行される前にのみ下書きに設定されます。

ルールを発行するときに、状態を [アクティブ] または [非アクティブ] に設定できます。

• ルールがアクティブな場合、リアルタイムの運用トラフィックに影響し、すべてのイベントがルールに対して評価されます。
• ルールが非アクティブな場合、運用トラフィックには影響しません。

以前に発行したルールを編集すると、発行済みルールの状態に応じて、ルールの 状態が [アクティブ (下書きあり)] または [非アクティブ (下書きあり)] に保存されます。

サンプル

ルールを作成または編集すると、 ページの右側に [サンプル ] ウィンドウが表示されます。 このウィンドウには、ペイロード サンプル用とスコア サンプル用の 2 つのセクションがあります。

ルールで使用されているサンプル変数を表示するには、[使用した変数の表示] を選択します。

ペイロードのサンプル

ペイロードのサンプルには、[ペイロードの設定] ウィンドウで定義されている評価の要求 API で送信できるフィールドの例が含まれています。 これらのフィールドは、ルールの変数として使用できます。

スコア付けサンプル

スコア サンプルには、Fraud Protection の AI モデルから生成されたスコアが含まれています。 関連付けられた AI モデルを実行してスコアを生成した後、ルールでスコア変数を参照できます。 たとえば、ボット評価の実行後に @"botScore" を使用し、リスク評価の実行後に @"riskScore" を使用できます。 詳細については、この記事の後半の 「句 」セクションを参照してください。

サンプルの編集

ルールがさまざまなイベントに対して機能することを確認するには、必要に応じてサンプルを編集し 、ルールに対してサンプル データを評価 します。 ペイロード サンプルとスコア サンプルの両方のすべての値を編集できます。 サンプルを編集しても、変更は Fraud Protection に送信する (または送信しない) データには影響しません。

ルールを発行すると、サンプルに加えられたすべての変更が保存され、ルールの一部として保持されます。

自分または他のユーザーがサンプルに加えたすべての変更を元に戻すには、[元に戻す] を選択します。 スコア サンプルはシステムの既定のスコア サンプルに戻され、ペイロードサンプルはペイロード設定ペインのユーザー定義ペイロード サンプルに戻されます。

条件

条件は キーワード (keyword) WHEN で始まり、ステートメントを True または False に評価するブール式が続きます。 評価されるルールを決定し、関連するビジネス ロジックをグループ化するための条件を作成できます。 たとえば、次の条件はデジタル製品トランザクションに関連しています。

WHEN @"productList.type" == "Digital"

その後、デジタル製品トランザクションに関連する不正行為戦略を構成する句を作成できます。

ルールへの条件の追加は省略可能です。 ルールをすべてのイベントに適用する場合は、条件を追加しないでください。 条件を使用してルールを並べ替える方法については、この記事で後述する「ルールの 順序付け 」セクションを参照してください。

句

句には、条件で定義されているトラフィックのセグメントに関連する不正ロジックとビジネス ポリシーが含まれています。 句では、イベント ペイロードの値と Fraud Protection の AI スコアを使用して、イベントの受け入れ、拒否、レビュー、チャレンジを行います。 各ルールには少なくとも 1 つの句が含まれている必要があり、各句には一意の名前が割り当てられます。 名前を選択してカスタマイズできます。

句の基本構造は次のとおりです。

RETURN <decision> 
WHEN <condition is true>

この構造を使用して、承認、却下、チャレンジ、またはレビューの決定を返す句を作成できます。 その後、決定に関する詳細情報を送信する省略可能なパラメーターを追加できます。

WHEN キーワード (keyword)の後のすべての値を True または False に評価できる必要があります。 このブール式は、イベント ペイロードからの値、ユーザー定義リスト、AI ベースのボットとリスク スコアで構成できます。

句の構文については、言語リファレンス ガイドを参照してください。

句がトリガーされると (つまり、WHEN ステートメントが True を返すとき)、RETURN ステートメントで指定された決定が返され、後続の句は実行されません。

条件が決定に一致するが、句がトリガーされない場合は、ルールが実行されます。

RETURN Approve("NO_CLAUSE_HIT")

句は、[ルール] タブに表示される順序で順番に実行されます。句の右側にある矢印ボタンを使用して、リスト内の位置を変更できます。

句はセクションにまとめられている。 AI モデルは、これらのセクションに基づいて実行され、評価の一部としてスコアが生成されます。 セクションは評価ごとに異なり、AI モデルに対して句がいつ実行されるのかを示します。

• 購入保護のために、トランザクションのリスク スコアを生成する AI リスク モデルが実行されます。 そのため、これらのルールには、すべてのスコア付け前の句と、リスク後のスコア付け句の両方が含まれます。
• アカウント保護の場合、ボット モデルはリスク モデルに加えて実行されます。 これらのモデルでは、それぞれボット スコアとリスク スコアが生成されます。 そのため、これらのルールには、すべてのスコア付け前の句、ボットスコアリング後の句、およびリスクスコアリング後の句が含まれます。
• カスタム評価の場合、AI モデルは実行されません。これらのルールには、すべてのスコア付け前の句のみが含まれます。
• 評価ウィザードを使用して作成された評価には、スコア付け前とスコア付け後の句の概念はありません。 代わりに、すべての句は、ルールに記載されている順序に基づいて順番に (上から下へ) 実行されます。

すべてのスコア付け前の句

すべてのスコア付け前の句は、Fraud Protection の AI モデルを実行する前に実行されます。 そのため、ボットまたはリスク評価スコアが生成される前に実行されます。 これらの句では、イベント ペイロードの一部として送信され、リストに含まれるフィールドの任意の組み合わせを使用できます。 これらは、禁輸措置、ジオフェンシング、またはその他のビジネス ポリシーを実装するように構成できます。

次の例は、ユーザーが地理的な場所以外の市場で製品を購入した場合の購入を確認するのに役立ちます。

RETURN Review("location inconsistency") 
WHEN Geo.MarketCode(@"device.ipAddress") != "@productList.market"

このセクションでは、クロスリファレンス リストに句を記述することもできます。 たとえば、Risky Emails という名前のカスタム リストがある場合、ユーザーのメール アドレスがリストに表示される場合、次の句はイベントを拒否します。

RETURN Reject ("risky email") 
WHEN ContainsKey ("Risky Emails", "Emails", @"user.email")

ルールのリストを参照するために使用される構文については、「言語リファレンス ガイド」を参照してください。

ボットスコアリング後の句

ボット スコアリング後の句は、Fraud Protection の AI モデルがイベントのボット スコアを生成した後に実行されます。 このスコアは、ボットがイベントを開始した確率を表します。 0 から 999 までの数値です。 スコアが高いほど、ボットの確率が高いことを示します。

ボットスコアリング後の句では、このスコアをペイロードとリストのフィールドと一緒に使用して意思決定を行うことができます。 このスコアは、@botScore変数を使用して参照します。 たとえば、次の句は、ボット スコアが 700 を超えるメイン特定の電子メール からのイベントを拒否します。

RETURN Reject()
WHEN @"user.email".EndsWith("@contoso.com") && @"botScore" > 700

リスクスコアリング後の句

リスクスコアリング後の句は、Fraud Protection の AI モデルがイベントのリスク評価スコアを生成した後に実行されます。 このスコアは 0 から 999 までの数値です。 スコアが高いほど、認識されるリスクが高いことを示します。

リスク スコアリング後の句では、ペイロードとリストのフィールドと共にこのスコアを使用して決定を行うことができます。 このスコアは、@riskScore変数を使用して参照します。 たとえば、次の句は、リスク スコアが 700 を超える高価なトランザクションを拒否します。

RETURN Reject("high price and risk score")
WHEN @purchasePrice >= 199.99 && @riskScore > 700

下書き

ルールには、公開バージョンと下書きバージョンの両方を含めることができます。 両方のバージョンは、[ルール] タブでサイド バイ サイド タブとして表示できます。

公開されたバージョンは読み取り専用であり、誰でも表示できます。 下書きバージョンは、作成者にのみ表示されます。 下書きを編集でき、すべての変更が自動的に保存されます。

• 下書きをカード解除するには、[Disカード] を選択します。
• 下書きを発行するには、[発行] を選択します。

下書きを発行すると、不正アクセス防止によって、発行されたバージョンのルールが下書きバージョンで上書きされます。

ルールの順序付け

[ ルール ] タブには、評価用に構成されている発行済みルールの一覧が表示されます。 ルールが一覧表示される順序は、ルールが評価される順序に影響します。 ルールの順序を変更するには、ルールを目的の位置にドラッグし、[保存] を選択 します。

イベントは、条件が True を返すまで、各ルールの条件に対して順番に評価されます。 選択したルールの各句が評価されます。 これらの句のいずれかが決定を返した場合、それ以上のルールは評価されません。 これらの句のいずれも決定を返さない場合は、トランザクションが既定で承認されるか、一致条件を持つ次に公開されたルールが評価されます。 動作は、 ルール設定で選択されているルールの評価動作 によって異なります。

新しいルールの作成

購入、アカウント作成、アカウント ログイン イベントに関連する決定を行うルールを作成できます。

重要

既定では、新しいルールが発行されると、[ルール] タブの [発行済みルール] セクションの一覧の下部に表示されます。ルールの位置を変更する方法については、この記事で後述する「ルールの順序を変更する」セクションを参照してください。

1. [ルール] タブで、[新しいルール] を選択します。

   新しい下書きルールが作成されます。 下書きに加えたすべての変更が自動的に保存されます。

2. [名前の変更] を選択し、名前と説明を入力します。

3. ルールに 条件 を追加します。

4. ビジネス ポリシーと不正行為戦略を表す句を追加します。

   • 新しい句を最初から作成するには、適切な句セクションで [新しい句] を選択します。
   • New 句の右側にある矢印を選択して、既存の 句テンプレートから開始することもできます。 テンプレートとその内容の完全な一覧を表示するには、[すべて表示] を選択します。

5. ルールを評価し、期待どおりに動作することを確認するには、[ルール] タブの右下にある [展開] を選択して、ルールの評価ウィンドウを開きます。

6. ルールを発行するには、[発行] を選択します。 確認ダイアログ ボックスで、名前、説明、および状態を変更し、[発行] を選択します。

7. 状態を [アクティブ] または [非アクティブ] に設定します。

8. [ルール] タブの一覧でルールの位置を変更するには、ルールを選択し、新しい位置にドラッグして、[順序を保存] を選択します。

システム定義 (既定) ルール

不正アクセス防止では、環境ごとにルールが作成される場合があります。 たとえば、次の既定の規則が作成される場合があります。

• 既定のサポート ルール

不正アクセス防止機能の中には、既定のルールに依存するものもあります。 電子メール、IP アドレス、またはその他の既知のリスト コンテンツをサポート リスト (セーフ、ウォッチ、または拒否) に追加すると、この既定のルールにより、評価評価中にリストがチェックされます。

システム定義ルールは、編集、削除、非アクティブ化できます。 ベスト プラクティスとして、既定の動作を変更しない限り、別のルールを作成または編集することを検討してください。

評価 (既定) ルール

評価ウィザードのテンプレートの選択ステップにメンション各評価テンプレートには、次の既定の規則のいずれかまたは両方が事前に定義されています。

• サンプル テンプレート ルール – このルールには、リスク スコア、ボット スコア、デバイス属性などの値に基づいて決定を行う独自のロジックを定義するための構成要素として機能する一連のサンプル句が含まれています (該当する場合)。 これらの句はいずれも既定では決定しませんが、提供されているサンプルを使用してすぐに変更できます。
• サポート リスト ルール – このルールは、Fraud Protection のサポート リスト (セーフ、ブロック、ウォッチ) を使用して、それらのリスト内のエンティティに基づいて十分な情報に基づいた意思決定 (同意、拒否、レビュー) を行う一連の句で構成されます。

該当する場合、これらの既定のルールは、評価の作成直後に [発行済みルール] の下にアクティブとして表示されます。 次の表は、評価テンプレートでサポートされる既定のルールの概要です。

Template	テンプレート ルール	サポート リストルール
カード支払い	サポートされています	サポートされています
デバイス フィンガープリンティング	サポートされています	該当なし
ロイヤルティ プログラム	サポートされています	サポートされています
送金	サポートされています	サポートされています
ソフトウェアの著作権侵害	サポートされています	サポートされています
Custom	該当なし	サポートされています

ルート環境と子環境の両方で、追加の規則と句を評価に手動で追加できます。

いずれかのテンプレートを使用して作成された評価のルール内から Fraud Protection のリスクとボット スコアを呼び出すには、次 のモデル関数 を使用する必要があります。

• リスク スコア: Model.Risk()。スコア
• ボット スコア: Model.Bot(@"deviceFingerprinting.id")。スコア

ブランチ

ブランチを使用すると、運用環境で発生している内容に影響を与えることなく、ルールを安全に変更できます。 [ルール] タブでブランチを作成できます。各ブランチはルールのコレクションを表します。 既定のブランチは運用ブランチであり、トラフィックが評価に送信されるたびに実行されるルールの分岐です。

分岐を作成する

新しいブランチを作成するには、「ブランチ」アクション>「新しいブランチを作成する」に移動します。 ブランチに名前を付け、API 名を指定し、ソース ブランチからコピーする規則を選択できます。 ソース ブランチは、[新しいブランチの作成] または [運用] を選択 したときに使用していたブランチです。 ブランチの作成時に下書きは保持されません。

ブランチ内のルールを変更する

非本番ブランチに対するルールの変更は、実稼働ルール スタックには影響しません。 ルールは通常どおり編集してブランチに発行できます。このブランチには、ルール ページにアクセスできるすべてのユーザーが表示できます。

テストと実験

ブランチ ルールの動作をテストするには、トラフィックをブランチに直接送信する方法と運用トラフィックをシャドウする方法の 2 つがあります。

ブランチにトラフィックを直接送信する

ブランチ アクション>ブランチ情報にあるブランチ API エンドポイントを使用して、評価でテスト トラフィックを特定のブランチに直接送信できます。 この API エンドポイントは、評価と同じペイロード構造を使用し、ブランチのルール スタックを実行します。

Note

トラフィックをブランチに直接送信しても運用環境には影響しないため、速度は更新されず、ブランチ トランザクションは検索に表示されません。

運用トラフィックをシャドウする

運用トラフィックをシャドウすることで、ブランチ ルールの動作をテストすることもできます。 運用トラフィックをシャドウするには、[実験の実行] を選択してブランチの実験を設定して開始します。 実験が進行中の場合は、[監視] タブで、実験が実行されているブランチに切り替えることで、そのパフォーマンスを確認できます。 実験が進行中の場合、そのパラメーターは編集できませんが、いつでも実験を停止して変更を加え、もう一度開始できます。 支払いサービス プロバイダー (PSP) ナビゲーション ビューでは、[ ブランチ アクション ] ドロップダウン メニューはルール ページにのみ表示され、監視ページには表示されません。

Note

ブランチ ルール スタックで実行されるシャドウされたトラフィックは運用環境に影響しないため、速度はシャドウの結果として 2 回更新されるのではなく、運用の実行の結果として 1 回だけ更新されます。

ブランチを運用環境に昇格させる

ブランチを本番ブランチにする場合は、ブランチを運用環境に昇格することで行うことができます。 昇格アクションは、ブランチ アクション>の [運用環境への昇格] にあります。 このアクションにより、新しい本番ブランチを昇格させる現在のブランチが作成されます。 既存の運用ルールを新しいブランチに複製して、参照用に保存することができます。 複製するオプションが選択されている場合、下書きは保持されます。 昇格が完了すると、昇格されたブランチのルールを含む本番ブランチが更新されます。

Note

特定の評価のためにブランチを運用環境に初めて昇格させる場合、新しいブランチで既存の運用ルールを複製することはできません。 昇格を初めて行う際に既存の運用ルールを保存する場合は、それらのルールを使用して運用環境から新しいブランチを作成し、既存の運用ルールを保持します。

既存のルールを管理する

[ルール] タブでは、既存のルールに対して次の操作を実行できます。

• 名前の変更
• アクティブ化または非アクティブ化
• 削除
• 編集

ルールの名前と説明を更新する

ルールの名前と説明を更新するには、ルールを選択し、[名前の変更] を選択して、一意の名前と説明を入力します。

ルールの状態を変更する

ルールの状態を変更するには、ルールを選択し、[アクティブ化] または [非アクティブ化] を選択します。

ルールを削除する

ルールを削除するには、ルールを選択し、[削除] を選択 します。 この操作は元に戻すことができません。

既存のルールを編集する

発行されたルールを編集すると、変更を発行するまで、Fraud Protection によって下書きとして保存されます。 選択したルールの発行済みバージョンと下書きバージョンの両方を、サイド バイ サイド タブとして表示できます。 下書きが公開されるまでは、作成したユーザーにのみ表示されます。 詳細については、この記事の前の 「下書き 」セクションを参照してください。

1. ルールを選択し、[編集] を選択 します。

   [下書き] タブと [発行済み] タブが表示されます。

2. [下書き] タブを選択し、ルールに変更を加えます。

   不正アクセス防止では、ルールに加えたすべての変更が自動的に保存されます。

   変更をカード解除するには、[Disカード] を選択します。 不正アクセス防止は下書きを削除しますが、元の発行済みルールは保持されます。

3. 変更を発行するには、[発行] を選択します。

   下書きを発行すると、Fraud Protection によって、発行された元のバージョンのルールが、下書きバージョンで行った変更で上書きされます。

   編集中にチームメイトがルールを更新して発行した場合、変更が古くなっている可能性があります。 この場合、変更を発行するかどうかを確認する警告メッセージが表示されます。

   • [発行] を選択すると、以前に行われたすべての変更が変更によって上書きされます。
   • [キャンセル] を選択した場合は、バージョンを公開する前に他のユーザーが行った変更を確認できます。

ルールを検索する

ルールを検索すると、すべてのルール名と説明が検索され、それに応じて結果がフィルター処理されます。

ルールを検索するには、[検索] フィールドにキーワード (keyword)を入力します。

フィルターを削除するには、[検索] フィールドからキーワード (keyword)を削除するか、フィールドの右側にある [X] を選択します。

ルールの順序を変更する

発行されたルールは実行順序で [ルール ] タブに表示されるため、発行されたルールの位置はイベントの評価方法に大きく影響します。

発行済みルールの順序を変更する

1. 移動する発行済みルールを選択し、新しい位置にドラッグします。
2. 移動するすべてのルールに対して手順 1 を繰り返し、[保存] を選択 します。
3. 変更を取り消すには、[キャンセル] を選択します。

Note

[下書き] セクションの ルールを並べ替えることはできません。

ルールを評価する

新しいルールを発行する前に、ルールの評価ウィンドウを使用して、期待した結果が返されることを確認できます。

• ルールの評価ウィンドウを開くには、[ルール] タブの右下にある [展開] を選択します。
• ウィンドウを閉じるには、[折りたたみ] を選択 します。

評価ウィンドウが開いている場合は、現在のペイロードサンプルとスコア付けサンプルに対してルールが評価されていることを確認できます。 サンプルまたはルール自体を変更すると、評価ウィンドウのコンテンツが更新されます。

評価ウィンドウには、サンプル イベントに対して Fraud Protection が返す決定が表示されます。 また、理由やサポート メッセージなど、応答に関連付けられている値も表示されます。 決定をトリガーする句は、ウィンドウの外側に緑色で囲まれています。

ペイロードサンプルが条件と一致しない場合、ルールは評価されません。 条件が一致しても、どの句も戻り値をトリガーしない場合、既定の決定は [承認] であり、理由はNO_CLAU Standard Edition_HIT。

評価の例

次の 3 つの句を含むルールを作成します。

`// Approves when email from contoso domain has been validated`
`RETURN Approve()`
`WHEN @"email.isEmailValidated" == true && @"email.emailValue".EndsWith("@contoso.com")`

`// Rejects when email has not been validated and high risk score`
`RETURN Reject()`
`WHEN @"email.isEmailValidated" == false && @"riskscore" > 700`

`// Reviews when email has not been validated and medium risk score`
`RETURN Review()`
`WHEN @"email.isEmailValidated" == false && @"riskscore" > 400`

ペイロード サンプルには、次のオブジェクトが含まれています。

"email": {
    "email": "Primary",
    "emailValue": "kayla@contoso.com",
    "isEmailValidated": true,
    "emailValidatedDate": "2020-02-25T15:12:26.9733817-08:00",
    "isEmailUsername": true
},

スコア サンプルには、次の値が含まれています。

"riskScore": 500,

評価ウィンドウが展開されると、句 1 がトリガーされ、承認の決定が返されます。

サンプル ペイロードでは、ペイロード内の isEmailValidated フィールドの値を true から false に変更します。

"isEmailValidated": false,

この場合、句 2 がトリガーされ、レビューの決定が返されます。

サンプル スコアでは、"riskScore" の値を 500 から 700 に変更すると、句 3 がトリガーされ、決定が [拒否] に更新されます。