01
Financial event
Events arrive from payment infrastructure through the selected connection.
Anti-fraud · Payment infrastructureSee the risk.
See the risk.
Understand the reason.
Configure the rules.
Assess financial events for suspicious activity. The Anti-fraud service analyses transactions against rules and helps adapt checks to your company's requirements.
Developed by MST Company · Configurable financial event assessment
Financial event assessmentRules and verdict
Logic configurationCustom rules · Lua
On-premise or Cloud-basedTwo service deployment options
Pre-processing or processingConnect to your payment infrastructure
Built-in and custom rulesAdapted to project requirements
The service's roleFrom a financial event
From a financial event
to a reasoned assessment.
Anti-fraud checks an event against defined conditions, returns a verdict and can identify a reason to decline a transaction.
02
Rules-based assessment
The service applies built-in and custom rules configured for project requirements.
03
Verdict and investigation
Assessment results and detailed logs help analyse suspicious activity.
POS terminalsMerchant location transactions
ATMsATM financial events
E-commerceOnline transactions
QR paymentsQR payment workflows
Service architectureChoose the environment.
Choose the environment.
Connect assessment.
Four architecture options combine service deployment location and connection point within payment infrastructure.
Where the service runs
What it connects to
Within your infrastructure.
Through pre-processing.
The service is installed in the customer's infrastructure. Financial event assessment connects to pre-processing.
Customer environment
POS terminals
ATMs
E-commerce
QR payments
Pre-processingPSP
Assessment request · Verdict
Anti-fraud ServiceRules-based assessment · Verdict
Bank processingBank infrastructure
Connection diagram based on service architecture. Channels send events to the payment environment; Anti-fraud returns the assessment.
Within your infrastructure.
Directly to processing.
The service is installed in the customer's infrastructure and connects directly to the bank's processing system.
Customer environment
POS terminals
ATMs
E-commerce
QR payments
Bank processingBank infrastructure
Assessment request · Verdict
Anti-fraud ServiceRules-based assessment · Verdict
Connection diagram based on service architecture. Channels send events to the payment environment; Anti-fraud returns the assessment.
On the provider's servers.
Through pre-processing.
The service runs and is maintained on the provider's servers. Customer infrastructure connects through an API; event assessment connects to pre-processing.
Customer environment
POS terminals
ATMs
E-commerce
QR payments
Pre-processingPSP
Bank processingBank infrastructure
API · Assessment request and verdict
Provider environment
Anti-fraud ServiceRules-based assessment · Verdict
Connection diagram based on service architecture. Channels send events to the payment environment; Anti-fraud returns the assessment.
On the provider's servers.
Directly to processing.
The service runs and is maintained on the provider's servers. Customer infrastructure connects through an API; Anti-fraud connects directly to bank processing.
Customer environment
POS terminals
ATMs
E-commerce
QR payments
Bank processingBank infrastructure
API · Assessment request and verdict
Provider environment
Anti-fraud ServiceRules-based assessment · Verdict
Connection diagram based on service architecture. Channels send events to the payment environment; Anti-fraud returns the assessment.
On-premise · Customer environment · Through pre-processing
Transaction flow processingBuilt-in checks.
Built-in checks.
Flexibility for your business.
Preconfigured rules cover transaction parameters, amounts, statistics and individual exceptions. Select a group to explore.
Prohibited parameters
Filter events by parameters defined as prohibited.
Data quality
Check for invalid data in a financial event.
Transactions without 3DS
A rule to restrict transactions without 3DS.
Transactions without CVC2
A rule to restrict transactions without CVC2.
Amount and PIN confirmation
Built-in rule example: transactions over 100,000 without PIN.
Transaction amount limit
Built-in rule example: transactions over 1,000,000.
Permitted MCCs
Allow only defined merchant category codes.
Manual entry
Option to restrict manually entered transactions.
Statistical context
Assess events using accumulated statistics.
Refund monitoring
Monitor refunds in transaction flows.
Transaction count and share
Rules based on counts and percentages relative to totals or averages.
Spikes and outliers
Monitor unusual spikes and outliers in transaction flows.
Blacklisted cards and BINs
Check against card and bank identification number blacklists.
Merchant declines
Assess high decline counts for a specific merchant.
Card transaction frequency
Monitor many transactions on one card within a short period.
Individual rules and exceptions
Additional conditions for Terminal IDs, merchants or groups.
The 100,000 and 1,000,000 thresholds illustrate built-in rule conditions. Parameters, currency, exceptions and applicability are defined for each configuration.
Add your own rules
Event assessment · DemonstrationOne event.
One event.
Different checks.
See how rule conditions change the result. The example compares amount and PIN confirmation, and transaction frequency for a fictional card.
Illustrative data and settings: amount threshold 100,000 and 10 transactions per 60 seconds. This explains logic, using neither real transactions nor universal service limits.
Financial event checkDEMO
Illustrative amount5 000
PINConfirmed
Card frequency2 per 60 s
Amount without PINOver 100,000
Card frequencyMore than 10 per 60 s
EXAMPLE RESULTNo rule matches
In this example, the amount is below the threshold, PIN is confirmed and frequency is within the limit.
Illustrative verification diagram. It does not reproduce the product interface, API response or log format.
Configuration and personalisationYour requirements.
Your requirements.
Your assessment rules.
A qualified anti-fraud analyst can adapt rules to new requirements. Embedded Lua supports custom checks.
- Modify existing rules
- New rules in embedded Lua
- Conditions for Terminal IDs, merchants and groups
- MST service configuration and adaptation
Rule logicLua · Extension
Transaction amount above threshold
AND
PIN not confirmed
↓
Rule triggered
Conceptual condition diagram. Not a rule editor or product API example.
Service benefitsTechnology for working
Technology for working
with transaction flows.
Flexible rules, fast checks, resilience and detailed logging underpin the service.
Verification
speed
The service is designed for rapid financial event assessment in transaction flows.
Resilience
of the service
Continuity requirements inform architecture and configuration selection.
Detailed
verification log
Detailed financial event verification logs support result investigation.
Integration
and deployment
API connection and optional deployment inside the customer's environment.
How to start working with usFrom the task
From the task
to deployment.
Tell us what works today and the result you want. We will define requirements and a project plan together.
Enquiry
Describe the task and requirements. Sign an NDA if needed.
Solution
Analyse the task, propose configuration and agree a project plan.
Agreement
Agree terms, timing and responsibilities, then complete the contract.
Implementation
Establish team communication and begin implementation.
We can develop the specification together.
MST specialists help define the task, configure the service and adapt it to your company's solution.
Questions answeredArchitecture,
Architecture,
rules and integration.
Key questions before designing an anti-fraud service.
What does Anti-fraud assess?+
The service analyses financial events against predefined rules and returns a transaction trust verdict. It can also identify a reason to decline the transaction.
Which payment channels are supported?+
The product page lists POS terminals, ATMs, e-commerce and QR payments. Data scope and connection method are defined during integration.
Where can the service be deployed?+
On-premise or Cloud-based. The first runs in the customer's environment. The second runs on the provider's servers, with API integration.
Is pre-processing required?+
Anti-fraud can connect through pre-processing or directly to bank processing. Both options are available for On-premise and Cloud-based deployment.
Can we change and add rules?+
Yes. A qualified anti-fraud analyst can adapt rules to project requirements. Custom rules can be added using embedded Lua alongside the built-in set.
Do built-in limits apply to every transaction?+
The figures illustrate rule conditions rather than universal transaction requirements. Currency, thresholds, exceptions and applicability depend on project configuration.
How do we start without a specification?+
Describe the current infrastructure, payment channels and intended outcome. MST specialists can help define a specification, select configuration and scope service adaptations.
Let’s discuss your needsRisk assessment.
Risk assessment.
In your infrastructure.
Describe payment channels, current architecture and event verification requirements. We will discuss connection, rules and service adaptation.
- Channels: POS, ATM, e-commerce or QR
- Environment: On-premise or Cloud-based
- Connection: pre-processing or processing
- Rules and individual exceptions
Loading the contact form…