---
title: Teams & their payload API
slug: grc-suite/teams-and-their-payload-api
createdAt: 2024-06-13T18:06:13.698Z
---

### Teams and Payload Structure

In the Transaction Monitoring System, each **team** within an organization is responsible for monitoring financial activities, such as transactions, and ensuring compliance. The system supports two main types of teams:

1. **Transaction Monitoring Team**: This team focuses on evaluating general financial transactions for potential risks or unusual activities.
2. **Anti-Money Laundering (AML) Team**: This team specializes in detecting transactions that may be related to money laundering or other financial crimes.

Each team is provided with a **payload structure** to submit transaction data for real-time monitoring. The payload is a standardized format used to evaluate incoming transactions against predefined rules. Below is an example of a typical transaction payload:

![](https://api.archbee.com/api/optimize/w0YdjmC6Uxu0AJ6sPj9OT/HCsF_7F3ymOWmtx7EwEdH_screenshot-from-2024-10-05-18-59-54.png "Transaction Payload Structure")

### Mandatory Elements in the TM  Payload

Every transaction payload in the system must include the following mandatory fields, which cannot be null:

1. **txn\_id**: A unique identifier for the transaction.
2. **customer\_id**: A unique identifier for the customer associated with the transaction.
3. **date\_time**: The date and time when the transaction occurred, in ISO format.

These fields are essential for ensuring that each transaction is accurately tracked and can be processed through the system’s rules engine.



![](https://api.archbee.com/api/optimize/w0YdjmC6Uxu0AJ6sPj9OT/smbFQvssEaCn9NpGhtBGD_screenshot-from-2024-10-05-21-54-31.png "Sample Transaction Mapping")

### Default Values for Other Mandatory Fields

In addition to the above, all other keys defined in the team payload are also **mandatory**. The default values for these fields are as follows:

1. **Float**:
   - Send a floating-point number, e.g., 12.0, 13.56.
   - If no data is available, send 0.
2. **Integer**:
   - Send an integer value, e.g., 155, 899.
   - If no data is available, send 0.
3. **DateTime**:
   - Send the date and time in **ISO 8601** format, e.g., "2024-09-25T10:45:30Z".
   - If no data is available, send an empty string "".
4. **String**:
   - Send text enclosed in double quotes, e.g., "Information".
   - If no data is available, send an empty string "".
5. **Boolean**:
   - Send true or false.
   - If no data is available, the **default value** should be false.
6. **Handling Sensitive Information**:
   - For sensitive fields like **cardNumber**, **customer\_id**, and other customer-specific data, you do **not** need to send the exact values.
   - You may send hashed or obfuscated values (e.g., customer\_id as 123abc4534abc12de) to protect customer privacy.
   - Ensure that the hashed value is **unique and consistent**, meaning if the same customer\_id is encountered again, the system should receive the same hashed value to correctly identify the customer.

Following these instructions ensures that the system processes the transaction correctly and efficiently.

### Example:

If a transaction's  **amount**, **cardType, riskScore** is unknown, it should be sent as:



::Image[]{src="https://api.archbee.com/api/optimize/w0YdjmC6Uxu0AJ6sPj9OT/xlgE6VQi-PAZysGt2I6f2_image.png" size="42" width="321" height="492" position="center" caption="Sample Transaction" showCaption="true"}

### Handling Invalid Transaction Payloads

If any required elements of the transaction payload are **missing** or if the instructions for sending the payload are **not followed**, the system will return a **422 Unprocessable Entity** error.

- **Status Code**: 422 (Unprocessable Entity)
- **Response**: "FAILED\_TO\_REGISTER\_TRANSACTION"

This error will be triggered if:

- **All elements** of the payload are not sent. Every field in the payload, as defined in the schema, must be included, even if a default value is being used.
- Incorrect data types are provided (e.g., a string is sent where a float or integer is expected).
- Default values are not respected (e.g., 0 for integer or float fields, "" for string or DateTime fields).

Make sure that all required fields are present in the payload, with correct data types and values, to avoid this error and successfully register the transaction.

### Dynamic Payload Structure

While the mandatory elements remain constant, the other keys in the payload can vary depending on the specific requirements of the rules defined by the team. For example, rules may require additional fields such as amount, currency, or txnType, based on the criteria used for evaluating transactions.

This flexibility allows teams to customize the transaction payload to match their specific monitoring needs while ensuring the essential details (txn\_id, customer\_id, and date\_time) are always included for tracking and rule evaluation

### Generating Team Payload  APIs

In the **Teams Page** under the **Settings** section, you can generate an API key for the team that you are currently part of. This API key allows you to integrate the system with external platforms. Follow the steps below to generate the API key:

1. **Go to the Teams Page**:
   - Navigate to the **Settings Page** and click on the **Teams** tab. The team that you are currently in will be displayed.
2. **Generate API Key**:
   - On this page, you will see a button labeled **"Generate API Key"**. Click on this button to generate a new API key for your team.
3. **Copy the API Command**:
   - After the API key is generated, the system will display the API command that includes the new key.
   - Copy this API command to use in external systems for integration.



![](https://api.archbee.com/api/optimize/w0YdjmC6Uxu0AJ6sPj9OT/GSFCMJvsQRZ3147iP12gy_screenshot-from-2024-10-01-21-44-37.png "API Key Generation in Teams Settings Page")

### Use the API Key:

The API key allows external systems to **send transaction data** directly to our GRC System. By using this API key, external platforms can authenticate and securely send transactions for evaluation based on your team's configured rules.

Store the API key securely, as it grants direct access to send transactions to your system. If the key is compromised, you can regenerate a new one by following the steps provided above.

This functionality enables seamless integration and secure communication between your system and external applications using the team-specific API key.

