> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/features/fraud-prevention.md). # Fraud Prevention Detect suspicious payment activity, stop known fraud sources, and use transaction insights to protect your revenue without unnecessarily blocking legitimate customers. The Fraud Prevention solution evaluates card and Pay by Bank transactions using configured risk rules, transaction history, and Block and Allow Lists. Depending on the result, a payment can continue normally, be marked as suspicious, or be declined. You can review fraud results in the Merchant Portal, understand why a transaction was flagged or declined, export suspicious activity for further analysis, and block identifiers associated with confirmed fraud. Fraud Prevention works automatically during payment processing, but its effectiveness also depends on the quality of the data provided by your integration and how consistently your team reviews and acts on the results. {% hint style="warning" %} No fraud solution can eliminate all fraudulent payments without also affecting some legitimate customers. Review your results regularly and use Block and Allow Lists carefully to maintain an appropriate balance between fraud protection and payment conversion. {% endhint %} *** ### Why Fraud Prevention Matters Ecommerce payments are Card-Not-Present or remote account-to-account transactions. The customer and payment instrument are not physically presented to you, which creates opportunities for stolen credentials, card testing, account takeover, identity misuse, and other fraudulent activity. Fraud can result in: * Loss of goods or services * Refunds and chargebacks * Operational investigation costs * Higher decline rates * Customer friction * Damage to your reputation The Fraud Prevention solution helps reduce these risks by evaluating transaction attributes and behaviour before or during payment processing. It can identify isolated high-risk transactions as well as patterns that become visible only when several payment attempts are considered together. *** ### Capability Summary | Capability | Support | | ----------------------- | -------------------------------------------------------------- | | Card payment evaluation | Supported | | Pay by Bank evaluation | Supported | | Real-time risk rules | Configured and managed by the bank’s risk analysts | | Transaction outcomes | Continue, mark as suspicious, or decline | | Transaction Viewer | Search, sort, review, and export fraud-related transactions | | Fraud reason details | Displayed for flagged and declined transactions | | Block List | Manage blocked card tokens, IP addresses, and email addresses | | Allow List | Available only to trusted merchants when enabled by the bank | | CSV export | Supported for fraud-related transaction lists | | Historical analysis | Rules can use up to six months of merchant transaction history | | Merchant-level controls | Block List and, where enabled, Allow List | | Bank-level controls | Rules and global or merchant-specific Block and Allow Lists | {% hint style="info" %} Available capabilities and access rights depend on your merchant agreement, configuration, and permissions granted by the bank. {% endhint %} *** ### How Fraud Prevention Works Fraud Prevention evaluates each supported payment using a defined sequence of controls: 1. **Block List check.** The transaction is checked against applicable bank-level and merchant-level Block Lists. 2. **Rule evaluation.** If no Block List match is found, the Rule Engine evaluates the transaction against the active fraud rules. 3. **Allow List check.** Where applicable, the transaction is checked for an allowed card that may qualify for an exemption from specific restrictions. 4. **Risk outcome.** The payment continues, is marked as suspicious, or is declined. 5. **Result visibility.** The fraud result and the applicable reason are made available in the payment response and Merchant Portal. The bank can apply controls globally, to a group of merchants, or to an individual merchant. Bank-level lists take precedence over merchant-level lists. {% hint style="info" %} **A Block List match always takes precedence over an Allow List match.** Adding a card to an Allow List does not permit it to bypass an applicable Block List entry. {% endhint %} The processing order and precedence of the controls are defined by the Fraud Prevention solution. *** ### Possible Outcomes #### Payment Continues The transaction does not match a blocking condition, or an applicable Allow List exemption permits it to proceed. The payment still continues through the standard payment process. For card payments, the issuer can still decline the authorization for reasons unrelated to the gateway’s fraud controls. #### Marked as Suspicious The transaction matches a rule configured to generate a warning rather than automatically decline the payment. A suspicious flag indicates that the transaction requires attention. It does not by itself prove that fraud occurred, and it does not necessarily mean that the payment failed. Review the transaction details and the triggered fraud reason according to your internal order-risk policy. For higher-risk goods or services, you may decide to delay fulfilment until the order has been reviewed. #### Declined The transaction matches a Block List entry or a rule configured to decline the payment. When several rules match and at least one of them requires a decline, the payment is declined. The result contains the fraud outcome and information about the applicable rule. Where several rules apply, only the first referenced rule is returned in the result. *** ### What the Solution Evaluates The Fraud Prevention solution evaluates the information available at the point where sufficient data has been collected for the selected payment method. #### Card Payments Card payments are evaluated after the customer selects a card-based payment method and provides card credentials or their tokenized equivalent. The evaluation can use information such as: * Transaction amount, date, and time * Card token * Card BIN, brand, issuer, and issuer country * Card expiry information * Cardholder name * Payment type, such as a regular or recurring payment * Merchant Category Code * Customer IP address and IP country * Customer email address and phone number * Billing and shipping addresses * Customer and merchant location information * Device information #### Pay by Bank Pay by Bank transactions are evaluated after the customer selects a bank and the gateway has received the information required for analysis. The evaluation can use information such as: * Transaction amount, date, and time * Payment token * Customer IP address and IP country * Customer email address and phone number * Billing and shipping addresses * Customer and merchant location information * Device information The exact information available for an individual transaction depends on the payment method, integration flow, customer input, and data supplied by your systems. *** ### Provide Complete and Accurate Data Fraud rules can evaluate only the data available to the gateway. Missing, generic, or inconsistent values reduce the solution’s ability to distinguish legitimate customers from suspicious behaviour. Where supported by your integration, provide: * The customer’s actual IP address * A valid customer email address * A stable customer or order reference * Billing and shipping addresses * Customer phone number * Accurate shopping-cart and transaction information * Device and browser information collected by the supported integration * The correct payment type for recurring or stored-credential transactions {% hint style="info" %} Do not replace real customer values with placeholders such as `unknown@example.com`, a fixed office IP address, or the same phone number for every transaction. For server-side integrations, make sure the IP address passed to the gateway represents the customer rather than your server or proxy. The Solution Description identifies the customer IP address as an important field for fraud analysis. High-quality payment data is also a standard requirement of leading fraud-management platforms: the more complete and accurate the transaction context, the better the system can distinguish suspicious behaviour from legitimate customer activity. {% endhint %} *** ### Risk Rules The Rule Engine evaluates transaction events, attributes, thresholds, and historical behaviour. Rules can consider: * The number of events during a defined period * The total transaction volume during a period * The average number of events * The average transaction amount * Differences between transaction attributes * Differences between current and historical merchant behaviour Examples of patterns that rules can identify include: * Several attempts with the same card in a short period * Repeated attempts using different amounts * Transaction volume that significantly exceeds the merchant’s usual activity * A mismatch between IP geolocation and shipping country * Unusual numbers of authorizations or declines associated with a BIN * Patterns indicating automated card testing or a BIN attack The Rule Engine can also monitor successful and unsuccessful payments, card reversals, and card or Pay by Bank refunds. {% hint style="info" %} Rules are created, tested, activated, and managed by the bank’s authorized risk analysts. Individual rules can be enabled or disabled for a specific merchant to reflect the merchant’s risk profile. Merchants do not create or modify rules through the Merchant Portal. {% endhint %} ### Review Fraud Results Fraud-related transactions are available in the Merchant Portal through the Payments and Fraud Prevention areas. You can: * Identify transactions marked as suspicious * Identify payments declined by fraud controls * Search and sort transactions * Review the reason why a payment was flagged or declined * Open the transaction details * Export the transaction list in CSV format * Add relevant transaction identifiers to your Block List Use the fraud reason together with the complete transaction and order context. A single attribute—such as a foreign IP address—may be legitimate on its own but more significant when combined with other signals, such as an unusual order value, mismatched delivery details, or repeated failed attempts. The payment response also contains the fraud result and the referenced rule reason, allowing API-integrated merchants to reflect fraud outcomes in their internal order-management processes. *** ### Block List Use the Block List to prevent new transactions associated with identifiers that you have confirmed as fraudulent or consistently high risk. Through the Merchant Portal, you can block: * Tokenized card identifiers from transaction details * IP addresses * Email addresses You can add an identifier from the fraud-related transaction view or manage entries through the Block List interface. Merchant Block List entries: * Take effect in real time * Do not require additional approval from the bank * Can be searched, reviewed, added, and removed * Apply to future matching payment attempts {% hint style="info" %} The gateway does not expose the customer’s full card number for Block List management. Card entries use the secure tokenized value available in the transaction details. {% endhint %} #### When to Add an Entry Consider adding an identifier when: * Fraud has been confirmed. * Several suspicious transactions share the same identifier. * A customer account or payment credential is known to be compromised. * The same source repeatedly performs card-testing or abusive payment attempts. * Your internal investigation establishes a clear connection to fraudulent activity. Avoid blocking an identifier solely because of one ambiguous transaction. Shared IP addresses, reused email domains, corporate networks, mobile networks, and public Wi-Fi can be used by multiple legitimate customers. #### Review the List Regularly Block List entries can prevent legitimate transactions after circumstances change. Review your list periodically and remove entries that are no longer justified. Use the most specific reliable identifier available. For example, blocking a confirmed fraudulent card token is usually more targeted than blocking a shared IP address. *** ### Allow List The Allow List is intended for exceptional cases where a known and trusted customer’s card should be exempted from specific fraud restrictions. Merchant access to the Allow List is available only when the bank designates the merchant as trusted and enables the functionality. Where access is enabled, you can add a tokenized card identifier and specify the expected transaction amount interval. The bank can define: * The maximum single-transaction amount that you may allow * Additional aggregate limits * Which restrictions may be bypassed * Whether Allow List management is available to your merchant account A transaction above an applicable aggregate limit can be marked as suspicious for further analysis even when it is not automatically declined. {% hint style="warning" %} **Use the Allow List sparingly.** Add only customers or partners whose identity, payment relationship, and expected transaction behaviour you have verified. An overly broad Allow List can allow fraudulent payments to bypass controls that would otherwise detect them. {% endhint %} The bank is notified when a merchant creates a new Allow List entry. Bank-level controls and all applicable Block List entries continue to take precedence. *** ### Make Fraud Prevention Effective #### 1. Send Meaningful Transaction Data Review your integration and make sure it sends the customer and order information available to your business. Pay particular attention to the customer IP address, email, phone number, billing and shipping details, transaction references, and correct payment type. #### 2. Review Suspicious Activity Regularly Assign responsibility for reviewing fraud results in the Merchant Portal. The appropriate frequency depends on your transaction volume and fulfilment model, but high-value or immediately fulfilled orders may require more frequent attention. Look for repeated identifiers and behavioural patterns rather than evaluating each transaction in isolation. #### 3. Define a Fulfilment Policy Decide what your business should do when a payment is: * Successfully completed without a fraud warning * Completed but marked as suspicious * Declined by fraud controls For suspicious orders, your policy might require additional order verification, delayed shipment, review of previous customer activity, or confirmation through an established customer contact channel. {% hint style="danger" %} Never ask a customer to send card credentials, security codes, banking passwords, or authentication codes as part of a fraud review. {% endhint %} #### 4. Block Confirmed Threats Add confirmed fraudulent card tokens, IP addresses, or email addresses to the Block List promptly. Record the reason for the decision in your own case-management or customer-service process. Review entries later to reduce unnecessary long-term blocking. #### 5. Keep the Allow List Narrow Use Allow List entries only for verified exceptions. Define realistic amount ranges, review the entries periodically, and remove access when the trusted relationship ends. Never use the Allow List simply to resolve an unexplained decline. First review the fraud reason and contact the bank where the rule or restriction requires clarification. #### 6. Monitor False Positives A false positive is a legitimate transaction incorrectly identified as risky. Signs of excessive false positives can include: * Repeated complaints from known customers * A sudden increase in fraud declines without a corresponding increase in fraud * Legitimate customer segments being consistently blocked * Rules affecting a specific market, card issuer, or fulfilment scenario disproportionately Collect transaction examples and provide them to the bank’s support or risk team. The bank’s risk analysts can review merchant-specific outcomes and adjust applicable rules where appropriate. Leading payment providers similarly recommend testing and monitoring rules to ensure they block materially more fraudulent activity than legitimate payments. #### 7. Protect Merchant Portal Access Grant Fraud Prevention access only to users who need it. Block and Allow List changes affect live payment decisions and should be performed by trained, authorized personnel. Review user access regularly and remove access promptly when responsibilities change. *** ### Operational Workflow A practical day-to-day fraud workflow can follow these steps: 1. Review newly suspicious and fraud-declined transactions. 2. Examine the fraud reason, transaction details, customer history, and order context. 3. Identify whether several transactions share a card token, IP address, email address, device pattern, or delivery information. 4. Add confirmed fraudulent identifiers to the Block List. 5. Escalate unexplained patterns or possible false positives to the bank. 6. Use the Allow List only for a verified customer and only where the bank has enabled it. 7. Export fraud-related transactions periodically for internal analysis and audit evidence. 8. Compare fraud decisions with refunds, customer complaints, and confirmed fraud outcomes to improve your internal process. ### Important Limitations {% hint style="warning" %} Fraud Prevention does not: * Guarantee that every fraudulent transaction will be detected. * Guarantee that every legitimate transaction will be approved. * Replace EMV® 3-D Secure, secure account management, or your own order controls. * Verify that goods were delivered or that the customer is entitled to use a particular account. * Make fulfilment decisions on your behalf. * Replace investigation of customer account compromise or cybersecurity incidents. * Allow merchants to create or modify the bank’s fraud rules. The issuer, customer’s bank, or another payment provider may still decline a transaction after it passes gateway fraud controls. {% endhint %} *** ### Frequently Asked Questions
Which payments are checked? The solution evaluates card and Pay by Bank transactions. The point at which the check occurs depends on when the gateway has received sufficient data for the selected payment method.
What is the difference between suspicious and declined? A suspicious payment matched a rule configured to generate a warning. A declined payment matched a blocking condition and cannot continue through the current payment attempt.
Does a suspicious flag mean the transaction is fraudulent? No. It means that the transaction matched a risk pattern requiring attention. Review the transaction and order context according to your internal policy.
Why was a payment declined? Open the transaction in the Merchant Portal and review the fraud reason. The payment result contains the referenced rule or Block List reason. When several rules match, only the first referenced rule may be displayed.
Can I change the fraud rules? No. Fraud rules are managed by the bank’s authorized risk analysts. Contact the bank if you identify a recurring fraud pattern, an unexplained decline, or a possible false-positive issue.
Can I add a customer to the Block List? You can add a tokenized card identifier, IP address, or email address associated with confirmed fraud or high-risk activity. Merchant changes take effect in real time and do not require separate bank approval.
Can I add a customer to the Allow List? Only when the bank has classified your merchant account as trusted and enabled Allow List access. Entries are subject to the amount limits and conditions defined by the bank.
Does the Allow List override the Block List? No. Block List entries always take precedence.
Can I download fraud-related transactions? Yes. You can search, sort, and export flagged and fraud-declined transactions in CSV format.
Does Fraud Prevention replace 3-D Secure? No. Fraud Prevention and EMV® 3-D Secure provide different controls and work together. Fraud Prevention evaluates transaction risk, while 3-D Secure enables the issuer to authenticate the cardholder where required.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/features/fraud-prevention.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.