> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fraudeg.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Automated Fraud Decisioning: Allow, Challenge, Block

> Learn how FraudEG's decisioning engine converts risk scores and configurable rules into allow, challenge, or block outcomes for every transaction.

Decisioning is the process of converting a raw risk score and your configured business rules into a concrete action your application can execute. Rather than leaving your team to manually interpret scores and decide what to do, FraudEG's decisioning engine evaluates every transaction against your rule set and returns a single `decision` field in the API response — `allow`, `challenge`, or `block` — so your application can branch immediately without additional logic.

## Decision Outcomes

Every transaction response includes a `decision` field with one of three values:

### `allow`

The transaction passes your risk thresholds and rule conditions. Proceed normally — fulfill the order, log the user in, or complete the transfer. No additional verification is required unless your application has independent requirements.

### `challenge`

The transaction falls in a risk band that requires additional user verification before proceeding. FraudEG returns a `recommended_action` field alongside `challenge` to indicate the verification method most appropriate for the risk level — for example, `3ds_challenge`, `sms_otp`, or `email_confirmation`. Your application is responsible for initiating the challenge and reporting the outcome.

### `block`

The transaction exceeds your configured risk thresholds or matches a block rule. Reject the transaction immediately and do not fulfill it. Return an appropriate error to your user. FraudEG logs the block event and includes the contributing `signals` in the response for your records.

## Consuming the `decision` Field

The `decision` field appears at the top level of every `/v1/transactions/score` and `/v1/transactions/evaluate` response. Read it before taking any action on the transaction.

<Steps>
  <Step title="Receive the API response">
    Call `POST /v1/transactions/score` with your transaction payload. FraudEG returns the score, signals, and decision synchronously in the response body.
  </Step>

  <Step title="Read the `decision` field">
    Extract the `decision` value from the response. This is your authoritative action directive — your downstream logic should branch exclusively on this field, not the raw score.
  </Step>

  <Step title="Handle `allow`">
    Proceed with the transaction normally. Optionally log the `transaction_id`, `score`, and `signals` for reporting and model feedback.
  </Step>

  <Step title="Handle `challenge`">
    Initiate the step-up verification method indicated in `recommended_action`. After the user completes the challenge, report the outcome back to FraudEG using `POST /v1/decisions/{transaction_id}/outcome` so the result is factored into future scoring.
  </Step>

  <Step title="Handle `block`">
    Reject the transaction. Return a user-facing error message. Do not expose the internal reason for the block. Record the `transaction_id` and `signals` for your fraud operations team.
  </Step>
</Steps>

## Node.js Example

```javascript theme={null}
const response = await fraudeg.transactions.score({
  user_id: "usr_8f3k2p",
  amount: 349.00,
  currency: "USD",
  payment_method: { type: "card", token: "tok_visa_xxxx4242" },
  session_id: "sess_7Tz3mKpR9vLq",
});

const { decision, recommended_action, transaction_id, signals } = response;

switch (decision) {
  case "allow":
    await fulfillOrder(transaction_id);
    break;

  case "challenge":
    if (recommended_action === "3ds_challenge") {
      await initiate3DS(transaction_id);
    } else if (recommended_action === "sms_otp") {
      await sendSMSOTP(transaction_id);
    }
    break;

  case "block":
    logger.warn("Transaction blocked", { transaction_id, signals });
    throw new PaymentDeclinedError("Your transaction could not be completed.");

  default:
    throw new Error(`Unexpected decision: ${decision}`);
}
```

## Decision Overrides

You can programmatically override a decision — for example, after a fraud analyst reviews a transaction in your queue — using `POST /v1/decisions`.

```bash theme={null}
curl -X POST https://api.fraudeg.com/v1/decisions \
  -H "Authorization: Bearer feg_live_sk_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_4kR9mXpL2vQw",
    "override_decision": "allow",
    "reason": "manual_review_cleared",
    "analyst_id": "analyst_jsmith"
  }'
```

Overrides are recorded in the audit log with the analyst ID and reason, and they contribute to model feedback to improve future scoring accuracy.

## Configuring Rules in the Platform

The no-code rule builder in **Platform → Risk Rules** lets you define exactly how scores and signals map to decisions for your specific business context. You can:

* Set score-band thresholds per decision outcome.
* Add signal-based conditions (e.g., always block when `bot_detected` is present).
* Scope rules to specific flows — checkout, login, onboarding, or high-value transfers.
* Set rule priority to control evaluation order when multiple rules match.
* A/B test rule configurations against live traffic before fully rolling them out.

All rule changes are versioned and take effect within seconds of saving.

## Real-Time vs. Asynchronous Decisioning

| Mode             | Latency            | Use Case                                                                 |
| ---------------- | ------------------ | ------------------------------------------------------------------------ |
| **Real-time**    | \<100ms (p99)      | Checkout, login, onboarding — any flow requiring an immediate response   |
| **Asynchronous** | Seconds to minutes | High-risk transactions routed to a manual review queue; batch re-scoring |

In asynchronous mode, the initial API response returns `decision: "pending"` with a `review_id`. FraudEG sends the final decision to your configured webhook once review is complete.

<Tip>
  Use **automatic decisions** (real-time mode) for the vast majority of your transaction volume — they handle low and very-high risk transactions instantly. Reserve **manual review queues** for the medium-risk band where human judgment adds the most value. This keeps your operations team focused and avoids review queue overload.
</Tip>