Real-time API

A decision before every operation

Your system sends the transaction to YARDA before executing it and receives, in the same response, a decision, a score and the reasons behind them. A single HTTPS request, authenticated by your key, from any language.

Read the documentationRequest a demo

The call

A transaction in, an explained decision out

Five fields are enough: the reference, the date, the amount, the sender and the receiver. Every optional field, such as the corridor, the channel, the agent, the device or the date of the last SIM swap, refines the analysis. If your system names its fields differently, it can send them as they are: the mapping is set once, when you go live.

Request
POST /v1/predict/fraud
X-API-Key: <API_KEY>
Idempotency-Key: 2c5d0b8e-7a41-4c1f-9e3b-6d2f8a10c7e4
Content-Type: application/json

{
  "transaction": {
    "transaction_id": "TRX-2026-000184",
    "timestamp": "2026-10-18T09:42:11Z",
    "amount": 450000,
    "currency": "XOF",
    "sender_id": "CLI-004512",
    "receiver_id": "CLI-019877",
    "sender_country": "SN",
    "receiver_country": "CI",
    "channel": "agent",
    "transaction_type": "remittance",
    "agent_id": "AG-0231"
  }
}
Response (extract, illustrative values)
{
  "request_id": "5b9e0c4e-2f7a-4d3c-9a51-8c0d6f1e2a47",
  "transaction_id": "TRX-2026-000184",
  "decision": "alert",
  "final_score": 0.83,
  "thresholds": { "review": 0.5, "alert": 0.7, "block": 0.9 },
  "decision_cause": {
    "kind": "score_band",
    "decision": "alert",
    "reason_fr": "Score de 83, au-dessus du seuil d'alerte (70).",
    "reason_en": "Score 83, above the alert threshold (70)."
  },
  "reasons": [
    {
      "feature": "s_amount_vs_median_90d",
      "direction": "high",
      "value": 9.4,
      "typical": 1.1,
      "weight": 0.97,
      "source": "anomaly"
    },
    {
      "feature": "s_new_receiver",
      "direction": "high",
      "value": 1,
      "typical": 0,
      "weight": 0.61,
      "source": "anomaly"
    }
  ],
  "triggered_rules": [],
  "degraded": false
}

The response also contains each model’s score, the rules that acted and, where relevant, the adjustment made by your policy.

The decisions

Four decisions, each with its cause

The score ranks the transaction within your own traffic. Your thresholds, set in the console, turn it into a decision; an active rule or typology can impose a minimum decision. The decisive cause is written in French and in English, ready to show to an analyst.

  • allow

    Allow

    The transaction goes ahead. It remains recorded and can be reviewed later.

  • review

    Review

    The transaction goes ahead and joins your analysts’ queue for review after the fact.

  • alert

    Alert

    The transaction deserves a look before going further: it arrives in the alert queue with its reasons.

  • block

    Block

    The transaction should not be executed. This decision only exists if you have allowed blocking.

Integration

What to know for a calm integration

The API follows the practices of a financial service: one key per use, requests that can be retried safely, explicit limits and errors that say what to do.

  • Keys with limited rights

    Your administrator creates keys in the console, with a lifetime and chosen rights: send transactions, read results, send labels. A key is shown only once and never sent by e-mail.

  • Retry without duplicates

    With the Idempotency-Key header, a request sent again after a network failure gets the same response for 24 hours, with no second analysis.

  • Stated limits

    By default, 600 requests a minute per key and 1 MB per request. Past the request limit, the 429 response says when to retry.

  • An incident does not go unnoticed

    If a model cannot answer, the response says so and the decision follows the floor set in your policy, a review by default.

  • Pseudonymised on arrival

    Identifiers of people, phones, wallets, agents and devices are replaced with pseudonyms before anything is stored. Names and addresses, if sent, are never kept.

  • Documentation kept up to date

    The API reference is generated from its OpenAPI description: the fields it describes are the ones the service accepts.

Beyond scoring

The other calls your system makes

The same key gives access to the calls that complement transaction scoring.

  • Late labels

    Complaints, reversals, investigation outcomes: send up to 1,000 labels per call, so your models also learn from what you find out afterwards.

  • Sanctions screening

    Compare the name of one customer, or of 1,000 at a time, with the United Nations consolidated list and the national list of Côte d’Ivoire. The name is compared, then forgotten; a match is examined by a person, never applied automatically.

  • Read an analysis again

    Retrieve a past analysis by its request identifier, with its decision and its reasons.

Frequently asked questions

Do I need to send my customers’ names?
No. YARDA does not need them to score a transaction: send your internal identifiers, which are pseudonymised on arrival. Only sanctions screening needs a name, compared in memory and then forgotten.
What happens at the start, before any training?
Your rules and the typologies you switch on apply from the first call. The models are added once trained on your history, which a file import is enough to provide.
Can I combine the API and files?
Yes. Transactions that arrive through the API, by file or from the database feed the same history and the same console.

Ready to connect your system?

Read the documentation, then ask for access for your technical team or your provider.

Read the documentationRequest a demo