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

# Submit Transactions

### Overview

Submitting a transaction means sending the transaction data to Sigma so it can be analysed for fraud and risk. Every transaction your customers make (transfers, deposits, withdrawals, payments) can be submitted to Sigma in real time.

Sigma evaluates the transaction against your configured rules and returns a decision: **approve**, **review**, or **reject**.

### Submission Methods

There are two ways to submit a transaction:

| Method      | How it works                                                                                        | Best for                                                                           |
| ----------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| **Instant** | Sigma processes the transaction and returns a decision synchronously in the same API response       | Real-time transaction flows where you need an immediate decision before proceeding |
| **Webhook** | You submit the transaction and Sigma sends the result asynchronously to your configured webhook URL | Background processing where you don't need to block the transaction flow           |

For most integrations, **instant** is recommended. It lets you act on the result immediately, for example blocking a transaction before it settles.

### What to Send

When submitting a transaction, include as much data as you have. The more context Sigma receives, the more accurate its analysis. Key fields include:

| Field                     | Description                                                                                  |
| ------------------------- | -------------------------------------------------------------------------------------------- |
| `transaction_id`          | Your unique identifier for the transaction                                                   |
| `amount`                  | Transaction amount                                                                           |
| `type`                    | `debit` or `credit`                                                                          |
| `channel`                 | How the transaction was initiated: `card`, `transfer`, `ussd`, `mobile`, etc.                |
| `transaction_date`        | ISO 8601 timestamp                                                                           |
| `sender_account_number`   | Sender's account number                                                                      |
| `receiver_account_number` | Receiver's account number                                                                    |
| `sender_bank_code`        | Sender's bank code                                                                           |
| `receiver_bank_code`      | Receiver's bank code                                                                         |
| `device`                  | Device details (ID, model, OS, location) used for device-based fraud detection               |
| `anonymized_user_data`    | User profile data: account age, verification status, location, etc.                          |
| `screeningData`           | Names to screen against PEP, sanctions, and adverse media lists (see [Screening](screening)) |

You don't need to send every field. Send what your system has and Sigma adapts its analysis to the data available.

<Note>
  For a complete list of accepted fields and their formats, see the [Historical Data](historical-data) page which documents the full transaction data structure.
</Note>

### Understanding the Response

Sigma returns three key values in the transaction result:

**`action`**: what Sigma recommends you do with the transaction:

| Action    | Meaning                                                          |
| --------- | ---------------------------------------------------------------- |
| `APPROVE` | No significant risk detected. Transaction can proceed.           |
| `REVIEW`  | Risk indicators found. Flag for manual review before proceeding. |
| `REJECT`  | High-risk signals detected. Block the transaction.               |

**`risk_level`**: the overall risk score assigned to the transaction (low, medium, high).

**`triggered_rules`**: a list of any rules that fired on this transaction, helping you understand why a decision was made.

### How to Handle Each Outcome

* **APPROVE**: proceed with the transaction as normal
* **REVIEW**: hold the transaction and queue it for a compliance team member to investigate. You can view flagged transactions in the Sigma dashboard under Transaction Monitoring
* **REJECT**: block the transaction and notify the user. Log the decision for audit purposes

<Tip>
  You control what happens for each action. Sigma provides the recommendation and your system decides how to act on it. Some institutions auto-reject on `REJECT` but require human sign-off before acting on a `REVIEW`.
</Tip>

### API Reference

<CardGroup cols={2}>
  <Card title="Instant Submission" icon="bolt" href="../../api-reference/transaction-monitoring/endpoint/submit-transaction-instant">
    Submit a transaction and receive a synchronous decision.
  </Card>

  <Card title="Webhook Submission" icon="webhook" href="../../api-reference/transaction-monitoring/endpoint/submit-transaction-webhook">
    Submit a transaction and receive the result via webhook callback.
  </Card>
</CardGroup>