Skip to main content
Version: 1.1

Monitoring Reports

Report Contents​

Monitoring reports are generated at regular intervals to provide a systematic analysis of transaction activities over time. By examining these transactions periodically, the reports help identify patterns and anomalies in payment entities' behavior, which are essential for effective compliance and risk management.

Delivered in JSON format, these reports ensure compatibility and ease of integration with various systems. The schema is designed to be backward compatible, allowing for seamless updates and enhancements without disrupting existing integrations.

The components of an MIF Monitoring Report are:

  • id: Unique identifier for the report.
  • scope: Defines the type of monitoring report. Possible values include: "mif" (Merchant Initiated Fraud), "pfd" (Payment Fraud Detection), and "aml" (Anti-Money Laundering).
  • subject: Details about the entities being monitored, including:
    • type: Entity type (e.g., "cardholder", "merchant").
    • id: Entity identifier.
    • name: Display name of the entity.
  • reason: Information about why the report was generated.
    • title: Short description of the trigger. If a rule is triggered, this represents the title of the highest priority triggered rule.
    • description: Detailed explanation of the trigger. If a rule is triggered, this represents the description of the highest priority triggered rule.
    • rule_id: The identifier of the highest priority rule that is triggered.
    • triggered_rule_ids: An array listing all rule_id's of the triggered rules.
  • classification: Risk assessment, which may include:
    • fraudflag: Risk level indicator ("Black", "Red", or "Yellow"). This field is always present in MIF reports but nullable in others.
    • priority: An integer representing the numerical priority of the report (lower numbers indicate higher priority). If a rule is triggered, this represents the priority of the highest priority (so the lowest number) triggered rule. This field is always present in AML reports but nullable in others.
  • tags: Array of relevant categories or requirements.
  • transactions: Array of related transaction IDs.
Example MIF Report JSON
{
   "id": "8v124u87z4",
   "scope": "mif",
   "subject": [
      {
         "type": "merchant",
         "id": "8v124u87z4",
         "name": "Media Markt"
      }
   ],
   "reason": {
      "title": "Merchant | High Authorization Volume",
      "description": "Large fraction of high risk transactions that is CNP. Detected a relatively large amount of high risk transactions, when compared to the merchant's peer group. (Between 2022-02-07 11:59 and 2022-03-09 11:59.)",
      "rule_id": "rule-123",
      "triggered_rule_ids": ["rule-123", "rule-456"]
   },
   "classification": {
      "fraudflag": "red",
      "priority": 15
   },
   "tags": [
      "mandatory",
      "Visa & Mastercard requirements"
   ],
   "transactions": [
      "281024872sa3"
   ]
}

Reporting Schedule​

Fraudio generates monitoring reports on a fixed interval basis rather than in real-time. This scheduled approach allows our systems to analyze patterns of merchant behavior over time and identify potentially fraudulent activities that may not be apparent in individual transactions.

The analysis period covered in each report is included in the reason description, which indicates the timeframe during which suspicious activities were detected (as shown in the example above: "Between 2022-02-07 11:59 and 2022-03-09 11:59").

Report Delivery​

Unlike our transaction fraud product that utilizes an API, monitoring reports operate differently. The response and recommendations are not retrieved through an endpoint because the data is batched. Instead, we have implemented a system where reports are sent to a designated Slack channel or webhook, and are also accessible through our dashboards.

These reports are automatically generated and delivered through:

  1. Access via the Fraudio dashboard.
  2. A designated Slack channel.
  3. Webhook notifications (if configured).

Webhook Configuration​

To receive monitoring reports via webhook, you must submit your webhook URL to Fraudio for configuration. This setup requires action on Fraudio's side, as it cannot be self-configured by customers (yet).

To set up webhook notifications:

  1. Contact your Fraudio representative or email support@fraudio.com.
  2. Provide your webhook URL and any authentication requirements.
  3. Fraudio will configure the system to send reports to your webhook endpoint.

Once configured, your webhook will receive reports in your preferred JSON format (Current or Legacy) whenever new alerts are generated.