RTRA Monitoring API

Introduction

The RTRA Engine runs rules and validation checks against transactions produced by an internal ERP or core system. Rules can be activated or deactivated dynamically, set as temporary or permanent, and executed in sequence. Each transaction returns a result indicating whether it is cleared, placed on hold with a reason, or flagged with a reason, plus an assigned RTRA score.

This page documents the two integration endpoints third party providers use to work with the engine, the RTRA Check API and the RTRA Report API.

Every RTRA API call requires an API key that has access to the RTRA engine. Generate the key from the developer section of the Assentify Platform, then send it in the request header.

x-header-api-key: {{api key generated in Assentify developer section with access to RTRA}}

1. Sign in to the Assentify Platform and open the Developer section.
2. Generate an API key and grant it access to the RTRA engine.
3. Send the key on every request as the x-header-api-key header.

The main integration point for the engine. Submit a transaction for real time risk assessment. The response indicates whether the transaction is CLEAR, FLAG, or HOLD, along with explanations and any rules triggered.

Request body

Send a JSON body made up of four objects: sender, receiver, transaction, and device.

sender object

receiver object

transaction object

device object

Example request body:

{
  "sender": {
    "sender_id": "4343434",
    "first_name": "John",
    "last_name": "Doe",
    "dob": "1990-01-01",
    "address": "Beirut, Lebanon",
    "mobile": "0096171234567",
    "nationality": "LBN",
    "id_type": "Passport",
    "id_number": "RL123456789",
    "id_issue_date": "2020-01-01",
    "id_expiry_date": "2030-01-01",
    "home_coordinates": {
      "latitude": 33.8938,
      "longitude": 35.5018
    }
  },
  "receiver": {
    "first_name": "Fatima",
    "last_name": "Zein",
    "dob": "1988-06-15",
    "address": "Tripoli, Lebanon",
    "mobile": "+96176123456",
    "nationality": "LBN",
    "id_expiry_date": "2026-06-01"
  },
  "transaction": {
    "amount": 1200,
    "currency": "USD",
    "timestamp": "2025-04-10T12:30:00Z",
    "channel": "Agent Network",
    "agent": "IDDOJFOE93232",
    "operator_id": "324343232",
    "origin_country": "LBN",
    "destination_country": "SYR",
    "exchange_rate": 15000,
    "fee": 15,
    "purpose": "Family Support",
    "source_of_funds": "Salary",
    "description": "Monthly transfer to sister",
    "location_coordinates": {
      "latitude": 33.8886,
      "longitude": 35.4955
    }
  },
  "device": {
    "device_id": "device123",
    "os": "iOS",
    "ip": "192.168.1.100",
    "vpn_detected": false
  }
}

Responses (200 OK)

A successful call returns a status, an optional score, a message, the list of rules triggered, the AML screening block, and an audit_id. Depending on the number of configured AML screening rules, there can be several sender and receiver screening blocks (for example sender_screening_2).

Cleared, no rules triggered, score based on proximity:

{
  "status": "CLEAR",
  "score": 55,
  "message": "Transaction cleared successfully",
  "rules_hit": [],
  "score_insights": [
    {
      "rule_id": "R002",
      "proximity": "75%",
      "description": "Sender nearing $10,000 30-day threshold"
    },
    {
      "rule_id": "R005",
      "proximity": "50%",
      "description": "Suspicious receiver dispersion pattern"
    }
  ],
  "aml_screening": {
    "aml_screening_status": "CLEAR",
    "sender_screening_1": {
      "status": "NO_MATCH"
    },
    "receiver_screening_1": {
      "status": "NO_MATCH"
    }
  },
  "audit_id": "RTRA-AUD-456789123"
}

Flagged, rule triggered, no AML match:

{
  "status": "FLAG",
  "message": "Flagged: Sender exceeded $10,000 threshold",
  "rules_hit": [
    {
      "rule_id": "R001",
      "description": "Sender exceeded $10,000 monthly threshold"
    }
  ],
  "aml_screening": {
    "aml_screening_status": "CLEAR",
    "sender_screening_1": {
      "status": "NO_MATCH"
    },
    "receiver_screening_1": {
      "status": "NO_MATCH"
    }
  },
  "audit_id": "RTRA-AUD-456789124"
}

Held on an AML match, no rule triggered. When a party matches a screening list, the screening block adds type, match_score, dob_match, matched_entity, and source:

{
  "status": "HOLD",
  "message": "Hold: Sender matched PEP list",
  "rules_hit": [],
  "aml_screening": {
    "aml_screening_status": "HOLD",
    "sender_screening_1": {
      "status": "MATCH",
      "type": "PEP",
      "match_score": 91,
      "dob_match": true,
      "matched_entity": "John Doe - Politically Exposed Person",
      "source": "Dow Jones"
    },
    "sender_screening_2": {
      "status": "NO_MATCH"
    },
    "receiver_screening_1": {
      "status": "NO_MATCH"
    }
  },
  "audit_id": "RTRA-AUD-456789126"
}

Sample request

curl -X POST https://api.rtra.assentify.com/v1/api/rtra/check \
  -H "x-header-api-key: YOUR_API_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d @transaction.json

Where transaction.json contains your transaction payload, including the sender, receiver, transaction, and device information described above.

Return a paginated, filterable, and sortable report of transactions that were held (HOLD), flagged (FLAG), or scored for review (REVIEW, cleared but exceeded the score threshold). The report helps compliance and risk teams track risk patterns, review AML flags, and export audit logs. It can cover a specific period for a specific user or for all users.

Request body

{
  "start_date": "2025-04-01",
  "end_date": "2025-04-10",
  "score_threshold": 50,
  "status_type": ["HOLD", "FLAG"],
  "mobile": "0096171234567",
  "agent_id": "IDDOJFOE93232",
  "operator_id": "324343232",
  "channel": "Agent Network",
  "page": 1,
  "limit": 25,
  "sort_by": "timestamp",
  "sort_order": "desc",
  "export": "none"
}

Export options

Set export to control the response format:

Paginated JSON response

{
  "status": "success",
  "pagination": {
    "page": 1,
    "limit": 25,
    "total_records": 61,
    "total_pages": 3
  },
  "data": [
    {
      "transaction_id": "TXN-92382391",
      "status": "HOLD",
      "message": "Hold: Sender matched OFAC list",
      "timestamp": "2025-04-06T15:45:00Z",
      "score": null,
      "rules_hit": [],
      "channel": "Agent Network",
      "operator_id": "324343232",
      "aml_screening": {
        "aml_screening_status": "HOLD",
        "sender_screening_1": {
          "status": "MATCH",
          "match_score": 91,
          "matched_entity": "Fatima Khaled - OFAC",
          "dob_match": true,
          "source": "Lexus Nexis"
        }
      },
      "audit_id": "RTRA-AUD-8832HF9"
    }
  ]
}

Supported filters

Sorting

Sample request with filters and export

curl -X POST https://api.rtra.assentify.com/v1/api/rtra/report \
  -H "x-header-api-key: YOUR_API_KEY_HERE" \
  -H "Content-Type: application/json" \
  -d '{
        "start_date": "2025-04-01",
        "end_date": "2025-04-10",
        "score_threshold": 60,
        "status_type": ["HOLD", "REVIEW"],
        "mobile": "0096171234567",
        "agent_id": "IDDOJFOE93232",
        "operator_id": "324343232",
        "channel": "Agent Network",
        "page": 1,
        "limit": 20,
        "sort_by": "score",
        "sort_order": "desc",
        "export": "csv"
      }'

Both endpoints share the same set of failure codes.

Example error bodies:

// 400 Bad Request
{
  "error": "Missing required field: sender.last_name"
}

// 422 Unprocessable Entity
{
  "error": "Invalid format for sender.dob. Expected YYYY-MM-DD."
}

// 422 Unprocessable Entity (report)
{
  "error": "Invalid sort_by value. Allowed: timestamp, status, score."
}

// 500 Internal Server Error
{
  "error": "RTRA engine encountered an unexpected condition."
}

The behavior of both endpoints is driven by the RTRA Engine Configuration in the platform. Rules and AML screening rules are defined there, then applied to every transaction the Check API receives.

1. In the developer section, generate an API key and grant it access to the RTRA engine.
2. Define rules in the engine, and set each as active or inactive, temporary or permanent, and ordered for sequential execution.
3. Configure AML screening rules. The number configured determines how many sender_screening_n and receiver_screening_n blocks appear in the Check response.
4. Set the score threshold used to mark cleared transactions as REVIEW so they surface in the Report API.
5. Send transactions to /api/rtra/check and reconcile outcomes with /api/rtra/report.