User manual

Teams & their payload API

9min

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:

Transaction Payload Structure
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.



Sample Transaction Mapping
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:



Sample Transaction
Sample Transaction


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.



API Key Generation in Teams Settings Page
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.