Stripe のデフォルトルールは、機械学習を使用し、相当数の不正使用による決済を予測してブロックします。どの決済をレビューするか、許可するか、ブロックするかについてさらに詳細なコントロールを必要とするビジネスにとって、ルールは不正防止をカスタマイズ するための強力なツールとなります。

このガイドでは、Radar ルールに関連するさまざまなトピックを扱います。トピックには、使用できる 100 を超える Radar ルール、およびバックテストやルールの記述などに関するベストプラクティスが含まれます。

それでは始めましょう。

ルールの順番と階層の重要性

Radar ページにリストされているルールの順番は重要です。すべての決済はお客様が作成したルールに対して評価され、以下の順番で実行されます。

1. 3DS のリクエスト: Payment Intents API または Checkout とともに使用された場合に、3D セキュア認証をリクエストするルール。このルールに一致するかどうかにかかわらず、許可、ブロック、レビュールールがその後に評価されます。
   
2. 許可: 決済の処理を許可するルール。許可ルールを実装する際には注意が必要です。このルールは、3DS ルールを除く、すべてのルールに優先するため、使用には細心の注意が必要です。$100,000 以上を処理した加盟店のみが許可ルールを記述できます。
   
3. ブロック: 決済をブロックして拒否するルール。決済が拒否されると、レビューのルールで再度見直されることはありません。
   
4. レビュー: これらの決済は処理され、顧客は支払いを完了しますが、必要に応じて後で見直しできるようにフラグが付けられます。
   

これを実践するため、例として以下のルールを使用します。$10 未満の決済はすべて処理されます。これは、最初のルールが決済を許可するためです。よって、その後のルールは評価されません。同様に、これらのルールに従い、通常リスクレベルの、アメリカで行われた $1,500 の決済も、$1,000 を超える決済をブロックするルールがあるにもかかわらず、許可されます。これは、リストの 2 番目のルールで、アメリカで行われた通常リスクレベルの決済が許可されているためです。いったん特定のルールがトリガーされると、それ以降のルールは評価されません。

• $10 未満の決済を許可

• アメリカ国内の normal のリスクレベルの決済を許可

• リスクレベルが high の決済をブロック

• greater than $1,000 の決済をブロック

• outside the US で発行されたカードの決済を レビュー

ルール言語の早見表

ルールは SQL に類似しており、ルールを作成するために使用するデータタイプに基づき、使用できる演算子が異なります。以下はそれらをまとめた早見表です。

特定の属性またはメタデータ属性の存在を明示的に確認する場合は、!= 演算子ではなく、is_missing 関数を使用します。この関数に、欠落している可能性がある属性またはメタデータキーを指定します。たとえば、顧客のメールアドレスにアクセスできないすべての支払いに一致するルールを作成できます。

• Review if is_missing(:email_domain:)
  

または、顧客のメールアドレスが欠落して「いない」すべての支払いに一致するルールを作成することもできます。

• Review if !(is_missing(:email_domain:))
  

自然言語でルールを記述する

もっと簡単にルールを作成したい場合、または特定の不正利用シナリオへの対処に使用する属性がわからない場合は、AI を活用した Radar アシスタントを利用して自然言語のプロンプトを Radar の構文のルールに変換します。また、Radar アシスタントからルールを直接バックテストして、ルールを導入する前に、もっと以前に導入していたらどのようなパフォーマンスであったかを確認することができます。

一般的に使用される Radar ルール

以下は、さまざまな目的に基づいて、一般的に使用される Radar ルールの一部を挙げたものです。

カードテスティングまたはカードキャッシングの防止に役立つルール

既知の高リスクの SKU での不正防止に役立つルール

このルールでは、メタデータを使用するか、または支払い説明として SKU 情報を渡す必要があります。これらの決済は処理され、顧客は支払いを完了しますが、もう一度確認できるようにフラグが付けられます。

プリペイドカードのトライアル乱用の防止に役立つルール

不正利用を分析してルール作成に役立てる

不正利用の確認

最も効果的なルールを作成するには、自身のアカウントで発生している不正行為を十分に理解する必要があります。行われているさまざまな種類の不正利用ベクトルの特徴を把握することが重要です。以下のような問いについて検討してください。

• アカウントは、登録してすぐに新しいメールアドレスとカード保有者名を使用して不正な購入を行っていますか？

• 不正利用者は、長期間存在しているアカウントにアクセスして、異常に多額の購入を行っていますか？

• 不正利用は、特定のカードネットワーク、またはカード発行国に偏っていますか？

• 高速の不正利用が発生していますか (短時間での、同じカード、メールアドレス、または IP アドレスからの複数回数の試行)。

上記のスクリーンショットで、高速で発生する不正利用を見ると、authorized_charges_per_card_number_hourly または authorized_charges_per_ip_address_hourly を利用したルールではこのタイプの不正利用方法に対処できる可能性があります。

不正利用の推進要因に関する詳細なインサイトを得る

不正利用に関するインサイトを活用することで、取引データを手動で分析することなく、不正利用の原因を素早く特定して対処することができます。ダッシュボードのインサイトタブに、不正取引に関連した上位の属性が表示されます。インサイトタブから直接、その属性に対処するルールを追加できます。

ルールを作成するための 3 種類の属性

タイプ 1

オーソリ後の属性: 誰もが使用できる属性です。これらの属性を使用する際には、:cvc_check: のようにオーソリ後属性の前後にコロンを使用する必要があります。

以下は、オーソリ後属性の使用例です。

• Block if :address_line1_check: != 'pass' このルールを使用すると、カード発行会社により、入力された請求先住所の 1 行目がカード保有者の記録にある情報と照合され、一致しない場合には、支払いがブロックされます。このため、この確認が ‘unavailable’ の場合、このデータがカード発行会社で ‘unchecked’ の場合、またはこのデータがカード発行会社で ‘not_provided’ の場合、その決済はブロックされることになります。
  

タイプ 2

標準属性: 誰もが使用できる属性です。標準属性には、:card_bin: のように前後にコロンを使用する必要があります。標準属性は、4 つのカテゴリーに分けられています。

• 頻度に基づく属性 (カードテスティングやカードキャッシングの防止に有益)
  
• カードの詳細に基づいた属性
  
• 決済の詳細に基づいた属性
  
• 顧客の詳細に基づいた属性
  

一部の属性では値を文字列にする必要があり、また他の属性では値を数値にする必要があります。これを分かりやすく説明するため、各属性の例を示します。:card_bin: のように属性が文字列を必要とする場合には、例の中で数値は ‘ ’ に囲まれています。たとえば、:card_bin: = ‘424242’ のようになります。一方、数値が必要とされる場合には、:amount_in_usd: > 250 のように ‘ ’ がありません。

頻度に基づく属性

盗難にあったカードの不正使用、カードテスティング、カードキャッシングを防止するために特に有益な、頻度に基づく 4 種類の属性があります。

1. オーソリ: カード発行会社のオーソリに基づく
   
2. 支払い: 支払いに基づく
   
3. 支払い拒否: カード発行会社による支払い拒否に基づく
   
4. ブロック: Radar の機械学習によるブロックに基づく
   

さらに、オーソリ (発行会社によるオーソリ成功に基づく)、支払い (支払い試行に基づく)、支払い拒否 (カード発行会社による支払い拒否に基づく)、不審請求の申請 (不正使用として不審請求の申請が行われた以前の取引)、ブロック (Radar の機械学習によるブロックに基づく) を含む、支払い結果に基づく属性もあります。結果は、顧客の詳細 (メールアドレス、IP アドレス、氏名、または顧客 ID) と組み合わされて属性を形成します。

さらに、顧客の詳細 (メールアドレス、氏名) の頻度を、取引に使用されたカードや IP アドレスと組み合わせることもできます。言い換えると、頻度ルールには 2 つのタイプがあります。

1. 結果がオーソリ成功、支払い試行、支払い拒否、不審請求の申請、ブロックの場合の支払い結果に基づく (authorized_charges_per_email_hourly、blocked_charges_per_email_hourly など)
   
2. 顧客の情報とカードまたは IP の間のリンクに基づく (name_count_for_card_weekly、email_count_for_ip_hourly など)
   

頻度ルールでは、現在処理中の決済は含まれません。たとえば、authorized_charges_per_email_hourly は、過去 1 時間に特定のメールアドレスから発生した、支払い試行の成功数を示します。このため、特定時間における特定のメールアドレスからの初回の支払い試行では、authorized_charges_per_email_hourly の値は 0 です。初回が成功すると、同じ 1 時間内におけるそのメールアドレスからの 2 番目の支払い試行では、値は 1 となります。

カードの詳細に基づいた属性

決済の詳細に基づいた属性

顧客の詳細に基づいた属性

以下は、標準的な属性の使用例です。

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

このルールを使用すると、カナダ、ドイツ、アラブ首長国連邦で発行されたカードからの支払いはブロックされます。

タイプ 3

メタデータ属性: これらの属性は、お客様が Stripe に送信する属性によって決まります。これらの属性では、::Customer Age:: のように標準属性の前後に 2 重のコロンを使用する必要があります。メタデータ属性は、文字列または数値として機能できます。文字列として使用された場合には、メタデータ属性では大文字と小文字が区別されます。

メタデータを使用して、購入された SKU に基づいて支払いを手動レビュー対象としたり、またはリピート顧客の負担を減らすなどの、非常に強力なルールを作成できます。より多くのメタデータを渡す方法については、ガイドをご覧ください。

メタデータ属性は、以下の構造で記述されます。

• ::[メタデータ属性名]:: [演算子] [メタデータ値]
  

メタデータフィールドに、以下のキーと値のデータが保存された決済があると仮定します。

以下の条件に一致する決済をレビュー対象とするルールを記述できます。

• Review if ::Customer Age:: < 30
  

さらに、このドキュメントで触れたメタデータ属性とサポートされるその他の属性の両方を使用してルールを記述できます。たとえば、Item ID が 5A381D に一致し、および決済額が US$1,000 を超える決済のみをレビュー対象にするルールを記述できます。

• Review if ::Item ID:: = '5A381D' and :amount_in_usd: > 1000
  

メタデータ属性は、複数の値に対して照合する IN 演算子もサポートしています。たとえば、Category ID が「groceries」、「electronics」または「clothing」のいずれかの場合にレビュー対象にするルールを記述できます。

• Review if ::Category ID:: IN ('groceries', 'electronics', 'clothing')
  

INCLUDES 演算子は、メタデータ属性とその他の文字列属性のルールで使用して、文字列の部分を照合できます。たとえば、Item ID に文字列 A381 が含まれる場合に決済をレビュー対象にするルールを記述できます。このルールは、「A381」、 「5A381D」、「A381D」、「5A381」などに一致します。

• Review if ::Item ID:: INCLUDES 'A381'
  

メタデータには、Customer オブジェクトと Destination オブジェクトでもアクセスできます (これらのオブジェクトが特定の決済で使用された場合)。これらの属性は、以下の構造で記述されます。

• ::[customer|destination]:[metadata attribute name]::[operator][metadata_value]:
  

以下のメタデータを持つ顧客がいると仮定します。

顧客の Trusted メタデータフィールドが true の場合は常に支払いを許可するというルールを作成できます。

• Allow if ::customer:Trusted:: = 'true'
  

または、デスティネーションに以下のメタデータがある場合:

デスティネーションの Category メタデータフィールドが new の場合に、決済をレビュー対象とするルールを記述できます。

• Review if ::destination:Category:: = 'new'
  

ルールで保存されたリストを使用する (許可リストやブロックリストなど)

以前に作成したリスト (許可リストやブロックリストなど) を通じて、ルールで値のグループを参照できます。メールアドレスのリストをブロックするには、ブロックする各メールに対してルールを作成する代わりに、ブロックリストを作成します。

ルールで参照されるすべてのリストエイリアスは、 @ で始まる必要があります。リストを参照するルールを作成するには、以下の構造に従う必要があります。

• {action} [attribute] in [list]
  

たとえば、ブロックしようとしているカード国のリストがあるとします。この場合、いくつかの OR 句を使用してルールを記述します。

• Block if :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'
  

または、インラインリストを使用してリストを記述することもできます。

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

または、card_countries_to_block という名前の、ブロック対象のカード国のリストを作成することもできます。国をそのリストに追加し、リストをルールで参照します。

• Block if :card_country: in @card_countries_to_block
  

リストを使用したルールは簡潔であるだけでなく、編集や多数のアイテムの追加が容易です。

複数の条件を組み合わせて複合ルールを記述する

演算子 AND、OR、NOT を使用して基本条件を組み合わせることにより、複合条件を作成できます。これらの演算子に対応する記号である &&、||、! も使用できます。Stripe は C、Python、SQL などのプログラミング言語と同様に、標準演算子の「優先順位」(演算の順序) に対応しています。たとえば、以下のような複合条件があるとします。

• {condition_X} OR NOT {condition_Y} AND {condition_Z}
  

これは、以下のように解釈されます。

• {condition_X} OR ((NOT {condition_Y}) AND {condition_Z})
  

括弧を使って、複合条件内のサブ条件をグループ化することもできます。たとえば、上の例を変更して、サブ述部の評価順序を明示的に変更することができます。

• ({condition_X} OR (NOT {condition_Y})) AND {condition_Z}

• {condition_X} OR NOT ({condition_Y} AND {condition_Z})

括弧を使用する位置が異なれば、複合条件の結果も異なります。

is_missing 関数は、OR または AND 結合でも使用できます。

• Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')
  

または、欠落値がなければ is_missing 関数を使用することもできます。以下の場合、:ip_country: が欠落しておらず、かつ IP が US か PR であれば、決済をブロックします。

• Block if !(is_missing(:ip_country:))AND :ip_country: IN ('US', 'PR')
  

バックテストのルール

ルール分析における一般的な考え方として、不正利用を防ごうとすると、誤検知によって正常な取引もブロックされる確率が高まります。バックテストを行うと、リスク選好度の範囲に収まるルールや、不審請求の申請の防止と誤検知増加の適度なバランスを保つルールを見つけることができます。ルールの影響を推定するには、Radar ダッシュボードにある過去 6 カ月間の取引データを組み合わせてバックテストを行い、より焦点を絞った分析を実施して、そのルールが最近適用されていた場合、どのように機能していたかを確認します。

ダッシュボードでバックテストを行う

不正使用とその他の正常な決済の構成要素の定義は、テストするルールタイプによって異なります。

ブロックルール

• 不審請求の申請が行われた、不正使用の早期警告を受信した、または不正使用として返金された: 不正使用のために不審請求の申請や返金が行われた成功した支払い、または不正使用のために不審請求の申請や返金が行われた、レビュー対象となった成功した支払い

• その他の成功した決済: 不正使用のために不審請求の申請や返金が行われなかった成功した支払いまたはレビュー対象となり、不正使用のために不審請求の申請や返金が行われなかった成功した支払い

• 失敗した決済の試行: カード発行会社によって拒否されたまたは Radar によってブロックされた

レビュールール

• 不審請求の申請が行われた、不正使用の早期警告を受信した、または不正使用として返金された: 不正使用のために不審請求の申請や返金が行われた成功した支払い

• その他の成功した決済: 不正使用のために不審請求の申請や返金が行われなかった成功した支払い

• 失敗した、またはすでにレビュー対象となった: カード発行会社によって拒否された、Radar によってブロックされた、またはレビュー対象となった成功した支払い (不審請求の申請や返金の状況に関係なく)

許可ルール

• Stripe またはカスタムルールによってブロックされた: Radar によってブロックされた支払い

• 不審請求が申請された、不正使用の早期警告を受信した、または不正使用として返金された: 不正使用のために不審請求の申請や返金が行われた成功した支払い、または不正使用のために不審請求の申請や返金が行われた、レビュー対象となった成功した支払い

• その他の成功した、または銀行によって拒否された決済: カード発行会社によって拒否された、不審請求が申請されなかった成功した支払い、 または不正使用のために返金されたか、または不正使用のための返金が行われなかった、レビュー対象となった成功した支払い

カスタムのバックテストによる分析を実行する

Radar ダッシュボードのバックテスト機能は、過去 6 カ月間の取引に焦点を当て、不審請求の申請、不正使用の早期警告、および不正使用として返金された支払いを対象とします。

たとえば、(不正使用の早期警告のみに焦点を当てた) Visa 不正使用モニタリングプログラムの対象となるリスクがある場合や、特定の IP 国やウォレットタイプからの不正使用が最近急増している場合には、より的を絞って分析することもできます。このためには、Sigma で SQL クエリを構築するか、ダッシュボードで決済データのレポートをエクスポートして分析できます。カスタムのバックテストを行うことで、時間枠が柔軟になり (6 カ月以上)、より的を絞った分析が可能になります (たとえば、不審請求の申請のみや EFW のみなど)。以下のクエリ例では、$100 を超える取引の Visa 不正使用の早期警告 (EFW) について、最近高額取引で不正使用が急増していて、リスクスコアの高い取引で監視プログラムのリスクが発生していると仮定してバックテストを行っています。

Using fields and tables available in Sigma

with base as (
    select
        c.id,
        c.amount,
        c.captured,
        e.created as efw_created
    from charges c
    left join early_fraud_warnings on e.charge_id = c._id
    where card_brand = ‘visa’
    and (c.amount / 100) >= 100
    and c.captured >= dateadd(‘day’, -180, current_date)
)

select 
    count(case when efw_created >= dateadd(‘day’, -60, current_date) then id else null end) as fraud_charge_count,

sum(case when efw_created >= dateadd(‘day’, -60, current_date) then amount else null end) as fraud_amount,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then id else null end) as false_positive_charge_count,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then amount else null end) as false_positive_amount

from base

EFW 作成日を基に過去 60 日間のデータをバックテストすると、直近の不正利用に焦点を当てることができます。一方、過去 60 ～ 120 日間の不正利用以外の販売データをバックテストした場合は、より進化した不正利用を確認できます。

不正利用の一般的な傾向

不正利用者の大半は、共通のパターンで不正利用を行います。まず、盗んだ決済情報（カードなど）を認証します。決済情報が機能していることを確認したら、その認証情報を使用して、さまざまな形で価値を引き出します。具体的には、個人使用または転売のための物理的商品 (高級品や電化製品) やサービス (食品配達サービス)、または別の不正利用に役立つサービスや製品 (ウェブホスティングサービスやメッセージスパムサービスなど) です。

最も一般的な不正利用の傾向や、それらを Radar ルールで軽減する方法については、以下の詳細をご覧ください。

テスト

カードテスティングとは、不正利用者がスクリプトや手動プロセスによって、盗んだカード番号がまだ有効かどうかを確認することです。この段階の目的は、物理的商品やサービスを得ることではなく、カードの有効性を検証することです。このような支払いは、一般的には少額の取引やオーソリです。基本的にカードテスティングは、短時間に連続して高速で行われます。これを検出するには、以下のようなグループ分けや速度の機能が役立ちます。

• total_charges_per_customer

• card_count_for_email

• card_count_for_ip_address

• total_charges_per_ip

これらを回避するために、不正利用者は偽のメールアドレスを複数作成して、それらを使い分ける傾向があります。より高度なテクニックを使用する不正利用者は、IP アドレスを秘匿したり、複数のデバイスを用いたりして一意のデバイスデータを提供します。この時点では、正常かつ典型的な顧客の操作を把握しておくことが重要です。さまざまなカテゴリーの中でも、メールドメインや IP の割り当て国などは、高リスクの取引を判断するのに役立ちます。不正利用者の多くは、gmail.com など、広く知られたメールプロバイダーの一般的なメールドメインを使用します。gmail.comms や gomail.co などのドメインも見られますが、これらは不正利用者が身元を隠ぺいするために使用しています。カードの発行国と IP の割り当て国によって顧客を分類し、ユーザーベースに多い地域からの取引であるかを確認することもできます。それ以外の地域からの取引は、レビューやブロックの対象にできます。

このテスティング行為を抑止する最後の方法は、 CAPTCHA の設定です。

Stripe Checkout では、機械学習がカードテスティング攻撃を検知すると、CAPTCHA チャレンジが自動的に表示されます。Stripe はカードテスティングを減らすために、カードテスティングモデルのトレーニングとあわせて、レートリミッターやアラート、継続的なレビューなど、一連の自動および手動のコントロールによって攻撃を自動検出しています。これらのモデルは、カードテスティング攻撃の進行中にのみ CAPTCHA チャレンジを表示するため、実際のユーザーにはほとんど表示されず、ボットに対してのみ CAPTCHA が表示されます。これにより、Stripe Checkout を使用している事業者ではカードテスティングが 80% も減少しましたが、購入完了率への影響はほとんどありませんでした。

なお、「特定の IP アドレスについて 3 回を超えて支払いを拒否された場合はブロックする」といったカスタムルールを作成することでも、カードテスティング攻撃を減らすことができます。

値の抽出

盗難クレジットカード (新しい行為)

この不正利用ベクトルでは、不正利用者が、確認済みの盗難カードを自分の個人用デバイスまたは不正利用行為に利用するデバイスで使用します。

このベクトルは通常、スクリプト化された大規模攻撃、またはより標的を絞った不正組織による小規模な攻撃によって悪用されます。いずれにしても、hours_since_email_first_seen_on_stripe など、Stripe でアカウント登録をして間もないかを確認するルール属性と、risk_score やその他の機能を組み合わせて使用することで、このようなまったく新しいカード保有者を阻止できます。さらに、IP、メール、カードに速度制限をかけることにより、不正利用者が盗んだ認証情報をできるだけ速く金銭化しようとする大量の攻撃から加盟店を保護できます。

盗難クレジットカード (隠ぺい行為)

この不正利用ベクトルでは、不正利用者が、個人のデバイス、または不正利用行為に利用するデバイスで、確認済みの盗難カードを使用するか、またはサブスクリプションアカウントを侵害し、アカウントに保存されているクレジットカード情報にアクセスします。

不正利用者は以下の方法を利用して、できる限り自身の存在を隠ぺいしようとします。

• 以前に完了した取引と同じ名前を使用する。

• 以前に完了した取引と同じ請求先住所を使用する。

• VPN を使用して、本来のカード保有者であるかのように見せかける。VPN で本来のカード保有者と同じ市や、時には同じ町内に見せかけることもあります。

• メールアドレスや電話番号など、あまり目立たない詳細のみを変更する。

• 物品の場合に、配送先住所を以前の取引のものから変更する。請求先住所と配送先住所の距離が大きく離れることもあります。この兆候はそれほど精度が高くありません。

上記で説明したような隠ぺい行為により、本来のカード保有者とアカウントを侵害した不正利用者のどちらが実際に取引を行っているかを解析することが困難になります。このため、加盟店も本来のカード保有者も、この種類の不正利用に長期間気付かないことがよくあります。

ここでも戦略は同じです。不正利用者は、盗んだ認証情報からできるだけ多くの価値を得ようとします。速度制限機能を使用するルールと、riskscore、cvccheck の失敗、または郵便番号の確認失敗を併用することにより、このような行為を防ぐことができます。

その他のベストプラクティス

以下に、Radar でのルール作成の最適化に役立つその他のベストプラクティスを紹介します。

Stripe.js を使用することの重要性

• 不正使用の信号を最適化するため、stripe.js を支払いの完全なパスに含める
  
• ページ読み込み時間に影響を与えずに Radar を最大利用するため、決済以外のページには stripe.js async を読み込む
  
• 一番シンプルなのは Google Analytics スクリプトタグの横に挿入すること
  
• gzip で圧縮された stripe.js バンドルの全体サイズは 29.6kb
  
  • 今後の状況: radar.js を stripe.js とは別に含められるようになる予定
    

結論

ルールは、不正使用に対する保護をカスタマイズする上で非常に強力なツールとなり得ます。このガイドで説明されている、ベストプラクティスに基づいた一意のロジックを実装することで、Radar にお客様のビジネスニーズ特有の不正防止設定を作成できます。

Radar for Teams の詳細については、こちらをご覧ください。

Radar for Teams をすでにお使いの場合には、ダッシュボードでルールのページを参考にして、ルールの記述を開始できます。

その他のメモ

プラットフォームでの Radar

Stripe Connect をお使いのプラットフォームの場合には、お客様が作成するルールはプラットフォームアカウントで作成された決済のみに適用されます (Connect の用語では、これらはデスティネーション支払いまたは代理支払いと呼ばれます)。
連結アカウントで直接作成された決済は、そのアカウントのルールの対象となります。

Terminal での Radar

Terminal の支払いは、Radar で評価されません。このため、Terminal を使用する場合、IP の頻度に基づいたルールを記述しても、対面支払いをブロックする心配はありません。