Skip to main content

Transaction Flow

FraudShield supports two submission workflows: an instant API response for live transaction risk assessment, or batch processing for transactions submitted on a schedule.

Monitoring vs Screening​

FraudShield processing falls into two main use cases: Transaction Monitoring and Transaction Screening.

Transaction Monitoring​

Transaction monitoring typically involves analysing batches of transactions over a period of time, identifying patterns and detecting potential suspicious activity retrospectively. It relies on historical data, risk models, and rule-based assessments to flag anomalies that may indicate fraud or money laundering.

This process is usually asynchronous, meaning that alerts and cases are generated after transactions have been processed, rather than in real time. FraudShield supports this method via the Batch Upload feature. Access the Batch Upload page, download the sample file to format your transaction data, upload the batch, and receive an email notification when processing is complete.

Transaction Screening​

Transaction screening on the other hand, is a real-time process that evaluates transactions as they occur. It checks transactions against the same risk patterns and models as Transaction Monitoring, but because it happens instantly, it is primarily used for regulatory enforcement and fraud prevention at the point of transaction execution.

FraudShield offers an API integration that allows a single transaction to be submitted and instantly processed. The API response includes a Risk Score, Risk Level, any rules that were flagged and, when a model is enabled, an AI risk assessment, letting you take the appropriate action in real time. For full instructions on integrating with the FraudShield API, see the API Reference.

End-to-end Transaction Flow​

The following diagram shows a typical end-to-end transaction flow:

1. Submission​

Submit the transaction using either the Batch File upload or API method. During submission, select which Environment to process the transaction in - Production or Test:

WorkflowBatch access methodAPI access method
Used when you have finished all testing and integration, for a live transaction.Select Production from the environment toggle on the top right of UI, then submit the Batch File.Select Production from the environment toggle on the top right of UI, create an API Key, then use that API key when submitting an API request.

2. Transaction and Customer Profiling​

The transaction is saved to FraudShield and can be accessed at any time from the Transactions page.

At the same time as saving the transaction, FraudShield will automatically create a new customer profile or update an existing one if the same Customer Identifier was used in a previous transaction. These customer profiles grow over time as more transactions are submitted, and can be accessed from the Customers page. They are a key part of allowing FraudShield to create advanced rules that deal with a customer's historical actions, such as tracking the frequency or volume of transactions they have made over a certain time period.

The profile will track the latest customer information, multiple accounts if they have been provided, and a history of any transactions and cases that person has been involved with.

3. Rule Evaluation​

The transaction is then automatically screened through your active Rule Plan. During setup, you define your monitoring scenarios as rules and group them into a Rule Plan. One Rule Plan is Active for each environment - Production and Test - allowing both to run simultaneously.

Rules

For a full explanation on all things Rules, you can refer to the Rules guide.

4. AI Risk Scoring​

When the active rule plan has an AI model enabled for the environment, FraudShield also gives the transaction an AI risk score from 0 to 100. The score shows how close the transaction came to breaching the rules in your plan, and is calculated independently of the rule results - it does not change when a rule triggers.

If the active plan has no model enabled, this step is skipped. If the AI Engine is unavailable, the transaction is processed on your rules alone. For the full picture, see How AI Risk Scoring Works.

5. Case Review​

Once processing is complete, check whether FraudShield has created a Case. A case is created automatically when:

  • A rule is flagged - One or more rules in the active plan flagged the transaction.
  • The AI risk score falls within an enabled range - No rule flagged the transaction, but its AI risk score falls within a range enabled in Auto Case Creation Based on AI Risk Score.

If no case is created, no further review is required. You can still raise a case yourself with Create Case on the Transaction Details page.

If a case is created, it can be viewed and further investigated from the Cases page.

The way you receive the processing result differs depending on the submission method.

Batch​

The Batch processing status will be displayed on the Batch Upload screen. Once batch processing is completed, you will receive an email notification if you have that particular email preference enabled. The email report will contain all the information about the transactions that were processed and any cases that have been created.

API​

For transactions submitted via API, the result is included in the response for a 200 Success request. The response contains the following fields:

  • caseDetails - Information relating to a case being created:
    • created - Boolean value of True/False, denoting whether a case was created after processing the transaction. A case is created when one or more rules are flagged during processing, or when no rule is flagged but the AI risk score falls within an enabled Auto Case Creation range.
    • id - Unique value assigned to the case. Only returned if created=true.
    • createdDate - Timestamp when the case was generated. Only returned if created=true.
    • riskLevel - Risk level of the case, set according to your organisation's Risk Level Assignment mode. By default this is the highest risk level of the flagged rules. For a case created from the AI risk score, it is the risk level of the matched range. Possible values are Urgent, High, Medium, Low. Only returned if created=true.
    • riskScore - Risk score of the case. Risk score is set to the total value of risk scores of the flagged rules. Only returned if created=true.
  • aiRiskAssessment - The result of AI risk scoring for the transaction. Always returned:
    • status - Outcome of AI scoring:
      • Scored - A model is enabled on the active rule plan and scoring completed.
      • NotEnabled - No model is enabled on the active rule plan for this environment, so the transaction was not scored. No other fields are returned.
      • Error - Scoring was attempted but did not complete. The transaction is still processed on your rules alone.
    • riskScore - AI risk score from 0 to 100, calculated independently of the rule results. Only returned if status=Scored.
    • errorMessage - Description of the scoring failure. Only returned if status=Error.
  • processedRules - Information relating to each rule that was processed:
    • ruleId - System generated ID for the rule.
    • ruleDisplayId - Rule Display ID.
    • ruleName - User specified name for the rule.
    • flaggedStatus - Status of the rule after transaction processing:
      • Flagged - Rule was flagged as being violated.
      • NotFlagged - Rule was not flagged as being violated.
      • Error - Error occurred during processing.
    • flaggedAccounts - Identifies if either the Source, Destination or both accounts caused the rule to be flagged.
    • riskLevel - User specified risk level for the rule. Possible values are Urgent, High, Medium, Low.
    • riskScore - User specified risk score for the rule.
    • influence - How much this rule mattered to the AI risk score, relative to the other rules. Only returned if aiRiskAssessment.status=Scored, and null when the model did not score the rule.
    • impact - How many points this rule pushed the AI risk score up or down, compared with a typical transaction. Only returned if aiRiskAssessment.status=Scored, and null when the model did not score the rule.

If a case was created via API, it will still be available for review from the Cases page as well.

Use this step to review the case and perform any business processes outside FraudShield.

6. Reporting and Audit​

The final step is to review whether any external reporting or auditing is required after the investigation is finished. All case activity is logged in its history, ready for regulatory submission if required.

What's next?

View the Case Investigation guide for an in-depth look at using the FraudShield case management tool to augment your investigation process.