# Daten zu angefochtenen Zahlungen und Betrug abfragen

Verwenden Sie Sigma oder Data Pipeline, um Informationen über Anfechtungen und Betrug abzurufen.

Die Tabelle `disputes` enthält Daten über alle [angefochtenen Zahlungen](https://docs.stripe.com/disputes.md) in ihrem Konto. Jede Zeile entspricht einem [Dispute](https://docs.stripe.com/api.md#dispute_object)-Objekt, das bei der Zahlungsanfechtung erstellt wird. Jede angefochtene Zahlung enthält außerdem alle verfügbaren Daten zu möglichen Nachweisen, auf die sich die Anfechtung stützt.
![](https://b.stripecdn.com/docs-statics-srv/assets/disputes.f293434123d316ff4fafe2524e9b2b0d.png)

Das folgende Beispiel zeigt einige vorläufige Informationen über die fünf letzten zu Ihren Ungunsten entschiedenen Zahlungsanfechtungen. Im Beispiel werden die Tabellen `disputes` und `charges` anhand der Spalten `disputes.charge_id` und `charges.id` zusammengefügt. Jede Zeile enthält neben der ID der Zahlungsanfechtung eine entsprechende Zahlungs-ID, den Betrag und das Ergebnis der PLZ- und CVC-Prüfungen.

```sql
select
  date_format(date_trunc('day', disputes.created), '%m-%d-%Y') as day,
  disputes.id,
  disputes.charge_id,
  disputes.amount,
  charges.card_address_zip_check as zip,
  charges.card_cvc_check as cvc
from disputes
inner join charges
on charges.id=disputes.charge_id
where disputes.status = 'lost'
and disputes.reason = 'fraudulent'
order by day desc
limit 5
```

| Tag      | ID                 | charge_id          | Betrag | PLZ            | CVC            |
| -------- | ------------------ | ------------------ | ------ | -------------- | -------------- |
| 6.5.2026 | dp_orWziM4j7CiRL8J | ch_orWziM4j7CiRL8J | 1.000  |                | Gebirgspass    |
| 6.5.2026 | dp_orWziM4j7CiRL8J | ch_orWziM4j7CiRL8J | 1.000  | Gebirgspass    | fehlgeschlagen |
| 6.5.2026 | dp_orWziM4j7CiRL8J | ch_orWziM4j7CiRL8J | 1.000  | fehlgeschlagen | fehlgeschlagen |
| 6.5.2026 | dp_orWziM4j7CiRL8J | ch_orWziM4j7CiRL8J | 1.000  |                | Gebirgspass    |
| 6.5.2026 | dp_orWziM4j7CiRL8J | ch_orWziM4j7CiRL8J | 1.000  |                | Gebirgspass    |

Bei der Erstellung von Berichten zu Ihren angefochtenen Zahlungen kann Sigma oder Data Pipeline helfen, betrügerische Zahlungen zu erkennen, die sich mit Stripe *Radar* (Stripe Radar helps detect and block fraud for any type of business using machine learning that trains on data across millions of global companies. It’s built into Stripe and requires no additional setup to get started) verhindern lassen.

## Daten für Radar for Fraud Teams

Wenn Sie Radar for Fraud Teams verwenden, verfügen Sie über eine Tabelle (`radar_rules`), die alle benutzerdefinierten Radar-Regeln mit ihren Aktionen und Eigenschaften enthält. Sie können diese Tabelle verwenden, um die `rule_id` anzufordern, die in der Tabelle `rule_decisions` verwendet wird, um alle von der Regel betroffenen Zahlungen zu finden. Dies liefert mehr Informationen als das Attribut `outcome_rule_id` in der `charges`-Tabelle, da es auch 3DS-Regeln anzeigt, die für PaymentIntents und SetupIntents ausgelöst wurden. Die [integrierten Radar-Regeln](https://docs.stripe.com/radar/rules.md#built-in-rules) haben feste rule IDs.

Das folgende Beispiel zeigt die letzten Zahlungen, die in einer Zulassungsliste genehmigt wurden, und deren Radar-Bewertung, um zu prüfen, ob betrügerische Zahlungen genehmigt wurden:

```sql
select
  outcome_type,
  card_cvc_check,
  count(*) as cnt,
  avg(outcome_risk_score) as avg_risk_score
from
  charges
where
  outcome_rule_id = 'allow_if_in_allowlist'
  and created >= current_date - interval '14' day
group by
  1,
  2
```

### Plattform-Daten

Mehrparteien-Zahlungsunternehmen wie Connect-Plattformen haben [besondere Anforderungen an das Risikomanagement](https://docs.stripe.com/connect/risk-management.md). Hier ist ein Beispiel für die Auflistung von [Destination Charge](https://docs.stripe.com/connect/destination-charges.md)-Unternehmen nach ihrer Anfechtungsquote:

```sql
select
  m.value as merchant_external_account_id,
  c.destination_id,
  arbitrary(a.business_name) as destination_name,
  count(*) as cnt_charges,
  count_if(c.paid) as cnt_success_charges,
  count_if(c.paid) * 1.0 / count(*) as success_rate,
  if(
    count_if(dispute_id is not null) > 0,
    count_if(c.paid) * 1.0 / count_if(c.paid),
    0.0
  ) as dispute_rate
from
  charges c
  left join charges_metadata m on m.charge_id = c.id
  and m.key = 'merchant_external_account_id'
  join connected_accounts a on a.id = c.destination_id
where
  c.created >= current_date - interval '120' day
group by
  1,2
order by dispute_rate desc
```

### 3D Secure-Daten

Sigma und Data Pipelines enthalten Daten zur 3D Secure-Authentifizierung (*3DS* (3D Secure (3DS) provides an additional layer of authentication for credit card transactions that protects businesses from liability for fraudulent card payments)). Dieses komplexere Beispiel zeigt für jede 3DS-Regel, wie häufig 3DS ausgelöst wurde und was die Ergebnisse waren, vorausgesetzt, es gab mehr als einen Versuch:

```sql
select
  rd.rule_id,
  count(distinct rd.id) as cnt_rule_triggered,
  count(distinct rd.payment_intent_id) * 1.0 / count(distinct rd.id) * 100.0 as pct_pis,
  count_if(at.is_final_attempt) * 1.0 / count(distinct rd.id) * 100.0 as pct_final_attempts,
  count_if(
    at.is_final_attempt
    and at.threeds_outcome_result = 'authenticated'
  ) * 1.0 / count(distinct rd.id) * 100.0 as pct_3ds_final_authenticated,
  count_if(
    at.threeds_outcome_result = 'authenticated'
    and at.charge_outcome = 'authorized'
  ) * 1.0 / count(distinct rd.id) * 100.0 as pct_3ds_authorized
from
  rule_decisions rd
  left join authentication_report_attempts at on at.intent_id = rd.payment_intent_id
where
  action = 'request_credentials'
  and rd.created >= current_date - interval '30' day
group by
  1
```

### Alle Attribute und Entscheidungen von Radar-Regeln

Sie haben ebenfalls Zugriff auf die Tabelle `radar_rule_attributes`. Jede Zeile enthält die meisten Werte der [Radar-Regelattribute](https://docs.stripe.com/radar/rules/reference.md#supported-attributes) für eine einzelne [Zahlung](https://docs.stripe.com/api/charges/object.md). Sie können die Tabellen `radar_rule_attributes` und `disputes` mithilfe der Spalten `radar_rule_attributes.transaction_id` und `disputes.charge_id` miteinander verbinden. So können Sie Regeln erstellen, die auf Ihre angefochtenen Zahlungen abzielen und Trends bei Ihren guten und schlechten Kundinnen und Kunden erkennen.

```sql
select
  card_3d_secure_support,
  is_3d_secure_authenticated,
  cvc_check,
  avg(risk_score) as avg_risk_score,
  avg(total_charges_per_card_number_all_time) as avg_total_charges_per_card_number_all_time,
  count(*) as cnt_disputes
from
  radar_rule_attributes r
  join disputes d on r.transaction_id = d.charge_id
where
  d.created >= current_date - interval '60' day
group by
  1,2,3
order by
  cnt_disputes desc
```

Weitere Details zu den verfügbaren Spalten finden Sie in unserem Leitfaden [[Wie Sie Ihr Betrugsmanagement mit Radar for Fraud Teams und Stripe Data kontinuierlich verbessern können](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data). Darin wird zum Beispiel erklärt, wo Sie Radar-Bewertungen zu Zahlungen und mehr finden.

## Verfolgung von Überwachungsprogrammen

Metriken zu [Kartenmarken-Überwachungsprogrammen](https://docs.stripe.com/disputes/monitoring-programs.md) sind schwer nachzuverfolgen, da die Regeln sehr spezifisch sind. Einige Details sind entscheidend, wie z. B. das Volumen oder die Anzahl der Transaktionen. Sie müssen nachverfolgt werden, um das Ausmaß von Betrug und Rückbuchungen einzuschätzen und umgehend Maßnahmen zu ergreifen, da die Benachrichtigungen der Überwachungsprogramme nicht sofort erfolgen. Wir empfehlen einen [kontinuierlichen Prozess](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) zur Verfolgung und Einschätzung von Rückbuchungs- und Betrugsmetriken.

Mit Sigma können Sie eine Abfrage schreiben, die die Betrugsrate einschätzt und simuliert, wie Kartenüberwachungsprogramme Ihre Zahlungen bewerten würden. Die folgende Abfrage ist nicht perfekt (wir gehen zum Beispiel davon aus, dass es sich um einen US-Händler handelt, bei dem inländische und grenzüberschreitende Zahlungen gezählt werden, Sie können die Abfrage für Ihren Anwendungsfall jedoch anpassen). Am wichtigsten ist jedoch, dass die Abfrage die Wechselkurse berücksichtigt und die gleiche Methode anwendet, um die Zahlungs- und Betrugszeiträume unabhängig voneinander zu ermitteln – so wie es die Überwachungsprogramme normalerweise tun.

```sql
with exchange_rates as (
  select
    date,
    currency,
    rate
  from
    exchange_rates_from_usd
    cross join unnest (
      cast(
        json_parse(buy_currency_exchange_rates) as map(varchar, double)
      )
    ) as t(currency, rate)
  where
    date = (
      select
        max(date)
      from
        exchange_rates_from_usd
    ) -- note the calculation for jpy is decimal and may look off
),
payments as (
  select
    -- technically these values are calculated per statement descriptor for CNP but we assume this equals merchant
    date_format(p.captured_at, '%Y-%m-01') as start_of_month,
    if(
      p.card_brand = 'Visa'
      or p.card_brand = 'MasterCard',
      p.card_brand,
      'Other'
    ) as network,
  	arbitrary(date_trunc('month', p.captured_at)) as month_datetime,
    count(*) as sales_count,
    -- For US, both Cross-Border and Domestic charges are counted
    -- we can ignore this in CBMP but show it here just to get a magnitude
    count_if(p.card_country != 'US') as sales_count_crossborder,
    count_if(pmd.card_3ds_succeeded) as sales_count_3ds,
    sum(p.amount / fx.rate / 100.0) as sales_volume_usd,
    sum(
      if(
        p.card_country != 'US',
        p.amount / fx.rate / 100.0
      )
    ) as sales_volume_crossborder_usd,
    sum(
      if(
        p.card_country = 'US'
        and pmd.card_3ds_succeeded,
        p.amount / fx.rate / 100.0
      )
    ) as sales_volume_3ds_us_usd
  from
    charges p
    join exchange_rates fx on p.currency = fx.currency
    left join payment_method_details pmd on pmd.charge_id = p.id
    -- for more information you may use
    -- left join authentication_report_attempts aa on attempt_id intent_id
  where
    p.captured_at >= date_trunc('month', current_date - interval '150' day)
    -- CBMPs only consider cleared amounts; refunds still count in the volume unless reversed
    and p.status = 'succeeded'
    and p.payment_method_type = 'card'
  group by
    1,
    2
),
efw as (
  select
    date_format(e.created, '%Y-%m-01') as start_of_month,
    if(
      c.card_brand = 'Visa'
      or c.card_brand = 'MasterCard',
      c.card_brand,
      'Other'
    ) as network,
    -- For US, both Cross-Border and Domestic charges are counted
    -- count_if(card_country != 'US') as efw_count_crossborder
    count(distinct c.id) as efw_count,
    count(distinct if(pmd.card_3ds_succeeded, c.id)) as efw_count_3ds,
    sum(c.amount / fx.rate / 100.0) as efw_volume_usd,
    sum(
      if(
        pmd.card_3ds_succeeded,
        c.amount / fx.rate / 100.0
      )
    ) as efw_volume_3ds_usd,
    -- for VSEFP
    sum(
      if(
        c.card_country = 'US'
        and pmd.card_3ds_succeeded,
        c.amount / fx.rate / 100.0
      )
    ) as efw_volume_3ds_us_usd
  from
    early_fraud_warnings e
    join charges c on e.charge_id = c.id
    join exchange_rates fx on c.currency = fx.currency
    left join payment_method_details pmd on pmd.charge_id = c.id
  where
    e.created >= date_trunc('month', current_date - interval '150' day)
  group by
    1,
    2 -- used for VAMP and ECM/ECP
),
disputes as (
  select
    date_format(d.created, '%Y-%m-01') as start_of_month,
    if(
      c.card_brand = 'Visa'
      or c.card_brand = 'MasterCard',
      c.card_brand,
      'Other'
    ) as network,
    -- For US, both Cross-Border and Domestic charges are counted
    -- count_if(card_country != 'US') as dispute_count_crossborder
    -- Because a payment can have multiple disputes, we count the disputes here
    count(distinct d.id) as dispute_count_all,
    count(distinct if(d.reason != 'fraudulent', d.id)) as non_fraud_dispute_count_all,
    count(distinct if(d.reason = 'fraudulent', d.id)) as fraud_dispute_count_all,
    count(
      distinct if(
        d.status = 'prevented',
        d.id
      )
    ) as dispute_count_rdr,
    count(
      distinct if(
        d.status != 'prevented',
        d.id
      )
    ) as dispute_count_exrdr,
    count(distinct if(pmd.card_3ds_succeeded, d.id)) as dispute_count_3ds,
    count(
      distinct if(
        d.reason = 'fraudulent'
        and pmd.card_3ds_succeeded,
        d.id
      )
    ) as fraud_dispute_count_3ds,
    count(
      distinct if(
        d.reason = 'fraudulent'
        and d.status != 'prevented',
        d.id
      )
    ) as fraud_dispute_count_exrdr,
    count_if(d.status = 'won') * 1.0 / count_if(
      d.status = 'won'
      or d.status = 'lost'
    ) as win_rate,
    -- The sum of disputes should match and can't exceed the payment
    sum(d.amount / fx.rate / 100.0) as dispute_volume_usd_all,
    sum(
      if(
        reason = 'fraudulent',
        d.amount / fx.rate / 100.0
      )
    ) as fraud_dispute_volume_usd_all,
    sum(
      if d.status != 'prevented',
        d.amount / fx.rate / 100.0
      )
    ) as dispute_volume_usd_exrdr,
    sum(
      if(
        d.reason = 'fraudulent'
        and d.status != 'prevented',
        d.amount / fx.rate / 100.0
      )
    ) as fraud_dispute_volume_usd_exrdr
  from
    disputes d
    join charges c on d.charge_id = c.id
    join exchange_rates fx on c.currency = fx.currency
    left join payment_method_details pmd on pmd.charge_id = c.id
  where
    -- current month data will usually be off due to dispute delays,
    -- we still show it as an indicator but it's better tracked weekly
    d.created >= date_trunc('month', current_date - interval '150' day)
  group by
    1,
    2
)
select
  -- theoretically this might cause gaps if there is a month
  -- without payments but a helper table with continuous dates would complicate this example query
  p.start_of_month,
  p.network,
  -- Used for VAMP/VSEFP/ECP/ECM/HEC
  p.sales_count,
  lag(p.sales_count, 1) over (
    order by
      p.network,
      p.start_of_month
  ) as sales_count_prior_month,
  p.sales_count_crossborder,
  p.sales_count_3ds,
  -- Used for VSEFP
  round(e.efw_volume_3ds_us_usd, 2) as efw_volume_3ds_us_usd,
  -- Used for VAMP/ECP/ECM/HEC
  d.dispute_count_all,
  d.dispute_count_rdr,
  d.non_fraud_dispute_count_all,
  d.fraud_dispute_count_all,
  d.dispute_count_exrdr,
  d.dispute_count_3ds,
  d.fraud_dispute_count_3ds,
  d.fraud_dispute_count_exrdr,
  round(d.dispute_volume_usd_all, 2) as dispute_volume_usd_all,
  -- Used for EFM
  round(d.fraud_dispute_volume_usd_all, 2) as fraud_dispute_volume_usd_all,
  round(d.dispute_volume_usd_exrdr, 2) as dispute_volume_usd_exrdr,
  round(d.fraud_dispute_volume_usd_exrdr, 2) as fraud_dispute_volume_usd_exrdr,
  d.win_rate,
  -- we show all the values below for all networks for comparison but they're only relevant for the indicated ones
  -- ECP/ECM/HECM based on prior month sales
  d.dispute_count_all * 100.00 / greatest(1,lag(p.sales_count, 1) over (
    order by
      p.network,
      p.start_of_month
  )) as all_chargeback_ratio_for_mastercard_percent,
  -- VSEFP
  e.efw_volume_3ds_us_usd * 100.00 / greatest(1,p.sales_volume_3ds_us_usd) as fraud_ratio_for_visa_3ds_percent,
  -- VAMP
  (d.dispute_count_exrdr + e.efw_count) * 100.00 / greatest(1,p.sales_count) as vamp_ratio_for_visa_percent,
  d.dispute_count_exrdr + e.efw_count as vamp_count_for_visa,
  -- EFM based on prior month sales
  -- Note different limits for Australia and 3DS regulations are not reflected here
  d.fraud_dispute_count_all * 100.00 / greatest(1,lag(p.sales_count, 1) over (
    order by
      p.network,
      p.start_of_month
  )) as fraud_ratio_for_mastercard_percent
from
  payments p
  left join efw e on p.start_of_month = e.start_of_month
  and p.network = e.network
  left join disputes d on p.start_of_month = d.start_of_month
  and p.network = d.network
order by
  start_of_month desc,
  network;
```