メインコンテンツへスキップ
このページで

DEUNAによる動的な認証と検証のオーケストレーション

決済のオーケストレーションは、決済プロセッサの選択に留まらないべきではありません。

多くの実用的な決済システムにおいて、最も難しい決定は、 具体的には、 トランザクションを送信するだけでなく、 どのような認証または検証が必要であるか、 決済が承認、再試行、承認、または拒否される前に、どの程度の検証が必要かを決定する必要があります。

ここで、DEUNAがその役割を果たします。

DEUNAのルーティングエンジンは、決済プロセッサの選択を超えて、 動的な認証およびトランザクション検証の決定をオーケストレーションできます 決済フローの中で、これにより、商社は、不正の発生状況、発行者の行動、取引属性、ユーザーのコンテキスト、およびゲートウェイからの応答信号に基づいて、必要な制御を挿入することで、価値を加える場合にのみ対応できます。

その結果、より適応的なアーキテクチャが得られます:

  • 誤検知の減少
  • 静的な拒否ルールへの依存の軽減
  • 実際に必要な取引に対するより強力な保護
  • 不正検出とコンバージョン間のバランスの改善
  • PSPおよび市場全体での一貫した不正検出ポリシー

このガイドで説明する内容#

このページでは、DEUNAを使用して、以下の認証および検証制御をオーケストレーションする方法について説明します:

  • 完全なEMV 3DS認証
  • 3DSデータのみ/データ共有のみパターン
  • マスターカードによるパスキーベースの認証体験
  • 生体認証および本人確認プロバイダー 例:顔認証またはデバイス認証
  • 手動レビューのオーケストレーション 不正行為の分析プロバイダーのレビュー機能を活用
  • 標準化された AVS オーケストレーション 発行元住所の確認応答を標準化し、普遍的な拒否ポリシーを適用

これは単なる決済経路のルーティング機能ではありません。 意思決定アーキテクチャ ここで、認証と取引の検証は、商人の決済戦略における設定可能な制御要素となります。


なぜ重要なのか#

多くの企業は、依然として厳格なモデルを採用しています。

  • 不正検出エンジンは 承認 → プロセッサに送信
  • 不正検出エンジンは reject → 支払いを拒否
  • ゲートウェイから AVS 応答が返される → 各 PSP は異なる方法で公開しており、企業は一貫して処理したり、無視したりする

このモデルはシンプルだが、コストがかかる。

主に以下の3つの問題が発生する:

  1. 誤検知:正当な顧客が、ルールが強すぎるために拒否される。
  2. 不要な摩擦: 危険と思われるすべてのケースは、より簡単な解決策が存在する場合でも、同じレベルの危険として扱われます。
  3. 承認後の制御が分散:ゲートウェイによって AVS などの応答信号が異なるため、統一された不正防止ポリシーの適用が困難

DEUNA は、企業がこの二者択一の決定をより詳細なフローに置き換えることを可能にします。

  • 高い信頼性の場合、直接承認
  • 低い信頼性の場合、より強力な認証を求める
  • 企業がコンバージョンを維持したい場合に、より少ないデータ共有パスを使用
  • カードリスクだけでなく、アイデンティティの確実性が重要な場合に、生体認証またはデバイス固有の検証を使用
  • AVS 結果を標準化し、承認を許可するか拒否するかを、単一のポリシーに基づいて決定

これは、異なる地理、発行者、リスクプロファイル、顧客セグメントを運営する企業にとって特に価値があります。


DEUNA のアプローチ#

DEUNA は、企業が認証と検証を 柔軟なトランザクション制御.

チェックアウトに固定された動作を組み込むのではなく、次のようなルーティングロジックを定義できるようにします。

  • 不正検出プロバイダーが承認した場合、承認に直接進む
  • 不正検出プロバイダーが拒否した場合、すぐに支払いを拒否しない
  • 拒否の理由、トランザクション金額、顧客の信頼レベル、発行者の行動、市場、または企業のルールセットを評価
  • 状況に応じて最適な認証手順を動的に呼び出す
  • 支払い応答が返されたら、AVS などの発行者とゲートウェイの検証アーティファクトを標準化し、単一のポリシーを適用
  • より強力な証拠またはコンテキストを備えたトランザクションを元のフローに再入力

これにより、DEUNAは以下の両方の制御プラットフォームになります。

  • 支払いルーティング
  • 認証ルーティング
  • 応答の標準化とポリシーの適用

この組み合わせは強力です。なぜなら、PSP、不正検出ツール、ゲートウェイ固有の AVS コードテーブル、およびカスタムチェックアウトロジックに散在する企業側の意思決定ロジックを一元化レイヤーに集中させることができるからです。


参照アーキテクチャ#

以下は、単純な概念的なアーキテクチャです。

フロー図
No step-upFull authenticationLightweight enrichmentDevice-native authIdentity certaintyHuman validationApproveRejectAcceptDenyEscalate1Checkout / payment intent2DEUNA orchestration layer3Risk evaluation inputs4Anti-fraud score / rejectreason5User profile / trusthistory6Amount / product /channel7BIN / issuer / market8Merchant strategy rules9Authentication decision10Send to processor11EMV 3DS123DS Data Only13Passkey flow14Biometric / identityprovider15Manual review queue16Review outcome17Automatic transactiondenial18Authorization response19Raw AVS / gatewayresponse20DEUNA AVS standardization21Universal policy22Approve / capture flow23Review / alternativeaction
商社または顧客DEUNA例外または停止プロバイダーまたはプロセッサレビューまたは保留中結果またはアウトカム

アーキテクチャの解釈

このモデルでは、DEUNAはチェックアウトの意図作成と最終的な支払い結果の間に位置します。

複数のシステムからの信号をインジェストし、ルーティングロジックを評価し、トランザクションを次のいずれかの状態に設定できます。

  • 追加のステップなしで継続
  • 追加のデータで強化
  • より強力なカード保持者認証にステップアップ
  • 支払い送信前に、追加のアイデンティティ検証制御を通過
  • 人間の判断がより適切な場合に、不正検出プロバイダーのレビューキューにルーティング
  • 承認応答後に、ゲートウェイの信号(AVS など)を一貫して標準化して解釈

このキーなアーキテクチャの違いは: 認証と検証は、もはや孤立した機能ではありません。トランザクションのオーケストレーションの一部となります。


DEUNA がオーケストレーションできる認証と検証制御#

1. フル EMV 3DS 認証#

より厳格な認証が必要な場合、DEUNAは、承認の前に、完全なEMV 3DSフローにトランザクションをルーティングできます。

一般的なトリガーには以下が含まれます。

  • 不正検知による拒否または、高いリスクスコア
  • 高額な取引
  • 初回購入者または、顧客の信頼に関する弱い信号
  • 疑わしいデバイス、トランザクション速度、または場所の変更
  • 発行機関、BIN、または、より高い不正リスクに関連する市場の状況
  • 加盟店または、規制要件による、より厳格な顧客認証

使用するタイミング

完全な3DSは、加盟店が… カード保持者の身元確認の強化 トランザクションの承認を試みる前に。

特に、商社がトランザクションの信頼性を高めるために、ある程度の手間を厭わない場合に有効です。

  • トランザクションに対する高い信頼性
  • より高度な不正防止
  • ネットワークと取引のコンテキストに応じて、潜在的なチャージバックと責任に関する利点

DEUNAのデザインにおける役割

DEUNAの役割は「3DSのオン/オフ」のみに限定されません。

以下のようなルーティング基準を使用できます:

  • トランザクション金額の閾値
  • 発行者またはBINセグメント
  • 不正行為防止の決定コード
  • 顧客の利用期間または信頼度
  • 商取引分野または国
  • 前の拒否後のフォールバック動作

これにより、加盟店は3DSを広範にではなく、特定の状況で選択的に利用できるようになります。


2. 3DS データのみ / データ共有のみのパターン#

すべての疑わしい取引を、完全なチャレンジに対応可能な3DSフローに移行する必要はありません。

特定の状況では、商社はコンバージョンを維持しながら、発行機関に詳細な情報を提供したい場合があります。その場合 データのみ または データ共有のみ パターンが有効になります。

その仕組み

これは、トランザクションおよび顧客データの3DSに関連する経路またはプログラムを通じて共有される、軽量なパスです。ただし、商人は 標準的な 3DS による完全なカード保持者認証を行わない 手順。

使用するタイミング

このパスは、以下の状況で役立ちます。

  • 取引金額が低く、追加のリスクをある程度許容できる場合
  • 取引が疑わしいものの、明確な詐欺行為ではない場合
  • 加盟店が、より良い審査結果を得ることを目指し、同時にチェックアウトのプロセスを大幅に変更しない場合
  • 取引の完了を優先し、より詳細な検証を強制しない場合
  • 加盟店が、よりスムーズなユーザーエクスペリエンスのために、より多くの詐欺リスクを負うことに同意する場合

アーキテクチャの価値

DEUNAの視点から見ると、これは以下の2つの要素の間に中間の層を追加します。

  • ハード承認
  • 完全拒否

これにより、完全な検証が必要ないものの、追加の審査情報から利益を得る取引に対して、より柔軟な復旧パスを提供できます。

言い換えれば、DEUNAは一部のトラフィックを以下のような場所にルーティングできます:

  • 完全な認証
  • 軽量な情報追加
  • または、ステップアップ機能が一切行われません。

販売者の戦略に基づいて。


3. Mastercard のパスキーベース認証#

マスターカードのパスキーベースの認証は、OTPに依存したワークフローへの依存を減らし、デバイスにセキュリティをより自然に組み込むことができる、新しい認証モデルです。

アーキテクチャ上の意味

Para los comerciantes, esto introduce una opción de autenticación adicional que puede ser más adecuada que los patrones tradicionales de desafío en algunos flujos de pago.

パスキーを別製品としてではなく、 既存のルーティングロジック内に統合できる認証モジュールとして位置づけることができます。 これにより、エコシステム全体でのサポートが容易になります。

使用するタイミング

以下のような利用例が考えられます:

  • 疑わしい取引:商社は、従来のOTP体験なしでも、より強力な認証を求める
  • カードオンファイルまたはリターニングユーザーの利用において、デバイスネイティブ認証を活用することで得られるメリット。
  • 高付与のユースケースにおいて、摩擦を最小限に抑えることが重要だが、IDの強さも維持する必要がある
  • 強力な認証連携が必要な市場やプログラム

DEUNAに適している理由

パスキーは、決済オーケストレーションが、プロセッサの切り替えを超えて進化する必要性を明確に示す例である。

現代的な商社は、次のように動的に決定できる:

  • 3DSを使用するかどうか
  • より軽いエンリッチメントパスを使用するかどうか
  • デバイスネイティブな認証方法を使用するかどうか
  • 直接承認に送信するかどうか

その決定は、DEUNAのようなルーティングエンジンに自然に属する。


4. 生体認証およびID検証プロバイダー#

一部の商人は、カードリスクモデルのみでは提供できない、より強力なアイデンティティの確実性を必要としています。

その場合、DEUNAは、決済フロー内で、生体認証またはID検証プロバイダーを条件付きの制御としてオーケストレーションできる。

例えば、以下の機能に対応できるプロバイダーがあります。

  • 顔認証
  • ライブネスチェック
  • デバイスの所有権チェック
  • 既知の顧客レコードとのIDの一致

使用するタイミング

これは、次のようなシナリオで特に役立つ:

  • アカウント不正取得リスク
  • 非常に高額な購入
  • 疑わしい初回ユーザー
  • 規制または機密性の高い商品カテゴリ
  • トランザクションを行う人が、より強く既知のIDと関連付けられるような、商社のフロー

アーキテクチャの価値

これらのプロバイダーは、すべての決済トラフィックに強制する必要はない。

DEUNAは、トランザクションパターンが、よりID中心の検証ステップを使用することを正当化する場合に、それらを選択的に使用できる。これにより、階層的な意思決定戦略の一部として、経済的および運用的に実現可能になる。


5. 手動レビューのオーケストレーション#

すべてのリスクのあるトランザクションを自動的に拒否する必要はなく、すべての境界線上のケースをより強力な顧客認証に強制する必要はない。

一部の商社にとって、適切な方法は、選択したトランザクションを 手動レビューキューに送信すること 、既存の不正検出プラットフォームによって駆動される。DEUNAは、これを、決済意思決定フロー内の別のオーケストレーションブランチとして扱うことができる。

その意味

このモデルでは、DEUNAは、トランザクションを、分析レビューまたはケース管理をサポートする不正プロバイダーにルーティングする。そのプロバイダーは、注文をレビュー状態に配置し、分析者または不正オペレーションチームが最終的な決定を下すことができる。

これは、次のようなプロバイダーに特に関連している:

  • レビュー決定をDEUNAに返す、サポートされている不正プロバイダーのレビューキュー
  • Accertify、そのプラットフォームと最近のガイダンスは、不正レビューワークフローの一部として、人間の専門知識、集中型のケース管理、アナリストの割り当て、およびエスカレーションルールを強調している

使用するタイミング

手動レビューは、次のような場合に適している:

  • トランザクションが高額または運用的に敏感である
  • 不正信号が曖昧であり、明確な不正行為ではない
  • 顧客が戦略的に重要であり、商社はハードな拒否を避けたい
  • 注文には、不正検知アナリストが判断する方が適切な特徴が含まれている場合があります。
  • 商社がすでに不正オペレーションチームを運営しており、DEUNAにケースをそのプロセスに投入したい

アーキテクチャの価値

手動レビューは、EMV 3DS、パスキー、または生体認証とは異なる。それは、 人間の検証パス としてより適切に理解できる、同じオーケストレーションモデル内にある。

それでも、DEUNAにとって非常に価値がある。商社は、次のように動的に決定できる:

  • トランザクションを自動承認するタイミング
  • 顧客認証に移行する必要があるタイミング
  • ID検証に移行する必要があるタイミング
  • そして、決済を失うのではなく、アナリストレビューが最適な次のアクションであるタイミング

典型的なオーケストレーションパターン

例としては、次のようなものがある。

  • 不正行為スコアがレビューバンドに該当する場合 → 即時拒否ではなく、手動レビューに送信
  • 初回利用者が、異常に高い注文額の場合 → 承認または履行前に、アナリストによるレビューを実施
  • 疑わしいものの、決定的なものではない取引 → 上流のスコアリングと手動レビューを組み合わせる
  • 戦略的に重要な注文で、不適切なAVSの結果 → 即時拒否ではなく、レビューにエスカレーション
  • 航空、旅行、チケット、またはデジタル商品の高リスクなシナリオ → 詐欺チームが、商社固有の判断を適用できるようにする

結果の処理

詐欺プロバイダーがレビュー結果を返した場合、DEUNAは、例えば、次のステップを適切にルーティングできます。

  • 承認 および、商社のフローに従って、承認、決済、または履行を継続
  • reject および、取引を停止
  • エスカレーション 商社がハイブリッドモデルを希望する場合、より強力な認証または身元確認パスにエスカレーション

これにより、DEUNAが単なるプロセッサのルーティング機能にとどまらない理由がさらに明確になります。自動化された不正行為システム、手動レビューオペレーション、および支払い実行の間の調整レイヤーとなります。


6. AVSのオーケストレーションと標準化されたAVS管理#

AVS(アドレス検証サービス)は、顧客が銀行に提出した請求書のアドレスと、発行者のファイルに登録されているアドレスとの照合を行うことで、不正を防止するための重要な信号です。

商社にとって重要なのは、AVSが有効かどうかではなく、PSPとゲートウェイがAVSを異なる方法で公開していることです。

  • 各PSPは、独自のAVSコードセットを返す可能性があります。
  • レスポンスのセマンティクスは、ゲートウェイとアキュイラーによって異なります。
  • 商社は、断片化されたマッピングと一貫性のない決定ルールを維持することになります。

DEUNAは、AVSを **標準化されたオーケストレーションレイヤーとして扱うことで、この問題を解決します。**単なるゲートウェイ固有のフィールドとしてではなく。

DEUNAが行うこと

サポートされているPSPを通じて取引が処理され、AVSデータが返された場合、DEUNAは、

  • PSPまたはゲートウェイから、生のAVSレスポンスを取得
  • そのレスポンスを、 単一のDEUNA AVSコードモデルに正規化
  • 加盟店は、DEUNA AVSコードを使用して、単一の不正利用ポリシーを定義できます。
  • 設定されたすべての決済戦略に、AVSデータを受信した場合に、このポリシーを自動的に適用します。

これにより、加盟店は、各プロバイダーごとに異なるAVSの解釈を維持するのではなく、単一で一貫した不正防止言語を使用できます。

これは、アーキテクチャ的に重要な理由

AVSは、3DSや本人確認の代替ではありません。異なる役割を果たします。

AVSは、 決済応答パスで返される検証信号として理解できます。 これにより、最終的な取引結果に実質的な影響を与える可能性があります。

そのため、DEUNAのアーキテクチャにおいて非常に価値があります。加盟店は、以下の機能を組み合わせることができます。

  • **不正利用スコアリングや、段階的な認証などの、**標準化されたAVSの解釈や、自動拒否ルールなど、
  • ポストレスポンス制御事前承認の制御

これにより、より包括的な意思決定プロセスを構築できます。

Deuna AVSの標準化

異なる決済ゲートウェイがAVS(住所照合)を異なる方法で処理するため、統一された不正対策戦略の策定が困難になります。

DEUNAは、異なるプロバイダーのAVSコードを標準化することで、この問題を解決します。 DEUNAのAVSコード は、理解しやすく、運用が容易です。

この標準化により、商人は複数のゲートウェイで再利用できる単一の不正対策ポリシーを作成できます。これにより、各ゲートウェイごとに独自のロジックを再構築する必要がなくなります。

自動トランザクションの拒否

DEUNAのAVSの最も強力な活用の一つは、ゲートウェイまたはプロセッサが通常は承認してしまう取引を、自動的に停止できる機能です。

たとえば、商人は特定のDEUNAのAVSコードを以下のように設定できます。

  • 常に許可
  • 常に拒否する
  • または、レビュー、代替ルート、または追加の検証などの下流アクションのためにエスカレーションする

これにより、商人のポリシーは、AVSの結果が商人のリスク許容範囲を満たさない場合に、ゲートウェイの盲目的な承認を上回ることができます。

使用するタイミング

AVSのオーケストレーションは、特に、商社が以下の目的を達成する際に役立ちます。

  • 複数のPSP(プロセッサ)で一貫した不正行為ポリシーを適用する
  • アプリケーションコード内のゲートウェイ固有のAVSコード処理を削減する
  • リスクの高い住所の不一致を迅速かつ一貫してブロックする
  • 請求先情報の検証を、より広範なリスクおよび認証戦略と組み合わせます
  • 不正行為の検出を改善し、すべての取引でより厳格な認証を強制する必要性を回避

DEUNAの戦略におけるAVSの位置づけ

AVSを動的認証の補完的なレイヤーとして使用することが一般的なパターンです。

例:

  • 低リスクの取引 + 良好なAVS結果 → 通常承認
  • 中リスクの取引 + 弱いAVS結果 → ポリシーに基づいて拒否またはエスカレーション
  • 不正行為拒否 + 商社がリカバリーパスを希望 → 承認前に3DSで対応
  • 承認された承認 + 不適切なAVS結果 → DEUNAのAVSポリシーに基づいて自動拒否

ここでDEUNAは、認証決定と支払い応答の検証の両方を同じオーケストレーションモデルで実行できるという、真のアーキテクチャ的価値を提供します。

DEUNA管理で自動拒否ルールを設定

一般的な運用フローは、以下の通り文書化できます。

  1. ログイン 使用する APM の評価用の不正検知プロバイダーを選択および設定します (例: Cybersource または Riskified)。.
  2. 以下のパスに移動する エラー管理.
  3. 開きます AVS設定.
  4. 貴社にとってリスクの高いDEUNAのAVSコードを選択します。
  5. 設定を保存する。

設定後、このポリシーは、AVSデータが利用可能なサポートされている戦略を通じて処理される取引全体で一貫して適用できます。


ソリューションアーキテクトがこの点について考えるべきこと#

良い実装は、「どこでも認証を追加する」ではありません。

良い実装は、 意思決定ツリー.

レベル1 - 直接承認
低リスク、信頼できる、反復的なパターンで使用します。

レベル2 – 軽度な認証
発行元情報が役立つが、完全な認証が変換コストが高すぎる場合は、「Data Only / Data Share Only」パスを使用します。

レベル3 – 強力なカード保持者認証
リスクが著しく高まった場合、またはより強力なカード保持者の証明が必要な場合に、完全な3DSを使用します。

レベル4 – 人間による検証
を有効にします。

レベル5 – より高い身元確認
トランザクションが標準の決済レイヤーのチェックを超えた信頼性を必要とする場合に、生体認証または身元確認の制御を使用します。

レベル6 – 応答検証の強制
決済応答が返ってきた後、承認を許可、拒否、またはエスカレーションするかどうかを決定するために、標準化されたAVSポリシーの強制を使用します。

この階層モデルは、以下の3つの一般的なアーキテクチャ上の誤りを回避するのに役立ちます。

  • 不必要な強固な認証の使用
  • 回復可能なステップアップパスの使用不足と、ハードな拒否へのデフォルト
  • ゲートウェイ固有のAVSのセマンティクスが、プロバイダー間で詐欺ポリシーを分割すること

例:意思決定パターン#

パターンA – 詐欺拒否の回復#

目的: 本来は拒否されるトランザクションを救済します。

例:ポリシー

  • 詐欺拒否と金額が高い場合 → 3DSを完全にトリガー
  • 詐欺拒否と金額が低い場合 → Data Onlyパスを試行
  • 不正防止が拒否した場合、かつ商人が強力な既存顧客に対する信頼がある場合 → サポートされている場合は、パスキーを有効にしたパスを使用
  • 詐欺拒否とユーザーの身元確認が重要 → 生体認証の検証をトリガー

これは、DEUNAの価値を示す明確な例です。詐欺拒否は、トランザクションの終わりではありません。

パターンB – ユーザー信頼セグメンテーション#

目的: すべての顧客に対して同じルールを適用しないでください。

例:ポリシー

  • 信頼できるリピーター → 直接認証または軽量な情報収集のみ
  • 異常なデバイスまたは地理的な行動を示すリピーター → パスキーまたは 3DS
  • 高額な注文を行う初回ユーザー → フル 3DS
  • 個人情報を含む注文を行う初回ユーザー → 生体認証

パターン C — コスト意識の高い認証戦略#

目的: 認証の深さを取引の経済状況に合わせて調整する。

例:ポリシー

  • 低額の注文 → ユーザーエクスペリエンスを維持し、まず軽い情報収集を行う
  • 中程度の額の注文で、リスクが中程度 → セレクティブな 3DS
  • 高額な注文または高額な詐欺の標的 → デフォルトでより厳格な認証
  • 戦略的に重要なが曖昧な注文 → 自動拒否ではなく、手動レビュー

これにより、加盟店は、すべての取引に対して、強力な認証のコストを一律に適用することを回避できます。

パターン D — 曖昧なトランザクションに対する手動レビュー#

目的: 人間による分析によって、不要な拒否を減らすことができます。

例:ポリシー

  • 詐欺プロバイダーがレビュー範囲のスコアを返す場合 → 取引を手動レビューに送信
  • 高額な初回注文で、複数の信号がある場合 → 分析担当者キューにルーティング
  • レビューが承認された場合 → 商人のフローに従って継続
  • レビューで拒否された場合 → 取引を拒否または履行をブロック

これは、すでに詐欺分析担当者を運用しており、DEUNAがレビューを完全に別のシステムとして扱うのではなく、手動レビューをオーケストレーションするようにしたい加盟店に特に役立ちます。

パターン E — PSP 間の一貫した AVS 拒否ポリシー#

目的: 複数のプロバイダーで、請求アドレスのリスク処理を標準化します。

例:ポリシー

  • ゲートウェイが DEUNA によってマッピングされた AVS コードを返す場合 → 許可
  • ゲートウェイが DEUNA によってマッピングされた AVS コードを返す場合 → 加盟店のポリシーに従って評価
  • ゲートウェイが DEUNA によってブロックされているパターンまたは利用できないパターンを返す場合 → 自動拒否
  • 加盟店が特定のセグメントに対してより柔軟な取り扱いを希望する場合 → ブロック拒否ではなく、レビューまたは下流アクションにエスカレーション

これにより、加盟店は、統合ごとに異なるコードテーブルを構築するのではなく、支払いゲートウェイ全体で 1 つの AVS ポリシーを管理できます。

パターン F — 統合された認証、レビュー、および AVS 意思決定#

目的: 取引フローの異なる段階で異なる制御を使用する。

例:ポリシー

  • 詐欺拒否を認証の前に → 3DS で回復
  • 受け入れがうまくいったが、AVS 結果が受け入れられない → DEUNA のポリシーに従って、承認後に拒否
  • 信頼できるリピーターで、強力な履歴と許容されるAVS → 最小限の摩擦で承認
  • 弱いアドレスマッチと高額な注文を行う初回ユーザー → より厳格な拒否またはより厳格な拒否

このパターンは、最適な詐欺戦略は、単一の制御ではなく、複数の制御を連携させて実行することであることを示しています。


DEUNA がルーティングロジックで使用できる入力#

堅牢な実装は、単一の危険スコアに依存するのではなく、複数の入力を組み合わせます。

一般的な入力には以下が含まれます:

  • 詐欺決定、スコア、または拒否理由
  • 顧客の履歴と信頼レベル
  • 取引金額とバスケットプロファイル
  • 製品の種類または注文の詐欺感度
  • BIN、発行者、カードタイプ、または国
  • デバイスまたはセッションの異常
  • 速度パターン
  • 加盟店の垂直方向のポリシー
  • 地理的な要件
  • セグメントごとの承認または詐欺の結果
  • サポートされている PSP またはゲートウェイから返される AVS 結果
  • 詐欺プロバイダーのレビュー範囲、キュー、または手動レビューの結果

これにより、DEUNA は、各プロバイダーの統合内にロジックをハードコーディングするのではなく、中央の意思決定エンジンとして機能できます。


実装上の考慮事項#

1. 意思決定を集中化する#

認証および検証ポリシーは、フロントエンドコード、PSP設定、および不正行為ツールに分散されるのではなく、オーケストレーション層に存在する必要があります。

2. リスクスコアリングとアクション選択の分離#

単独のリスクスコアは、最適なアクションを定義しません。

オーケストレーション層は、トランザクションに適したアクションをリスク信号に変換する必要があります。例えば:

  • 承認
  • 強化
  • ステップアップ
  • verify identity
  • AVSに基づいた拒否またはエスカレーションを適用
  • 手動レビューへのルーティング
  • 再試行またはフォールバック

3. 可観測性の設計#

商人は、以下の要素を含む各ブランチのパフォーマンスを測定する必要があります。

  • 以前に拒否されたトランザクションの回復率
  • 認証パスによる認証の向上
  • パスごとの不正行為率
  • 該当する場合、チャレンジ率と放棄率
  • ユーザーセグメントごとのコンバージョンへの影響
  • PSPおよびセグメントごとのAVS不一致率
  • 標準化されたAVSポリシーに基づく拒否率
  • コストと回復の経済性

4. 静的な一律ルールを避ける#

高額な初回ユーザーに適したルールは、低額の繰り返し顧客には有害となる可能性があります。

DEUNAは、商人がリスクとビジネスコンテキストに基づいて戦略を分ける場合に最も効果的です。

5. 認証情報を適切に扱う#

3DSがフローの一部である場合、実装は、現在のカードネットワーク、支払いプロバイダー、およびコンプライアンス規則に従って認証データを処理する必要があります。 CAVVまたはAAVなどの暗号化された認証値を長期間保存することはありません。DEUNAは、サポートされている承認フローに必要となる認証結果を渡します。商人は、元の暗号文をログや分析に保持しないでください。

6. AVSを唯一の情報源としてではなく、信号として扱う#

AVSは価値がありますが、それらを独立して解釈してはなりません。

最適な実装では、AVSを以下と組み合わせて評価します。

  • ユーザーの履歴
  • トランザクションの価値
  • 不正行為スコア
  • デバイスの動作
  • 市場固有の不正行為パターン

そのため、AVSは、スタンドアロンのゲートウェイルールではなく、オーケストレーションモデル内に存在する必要があります。