We are a service provider and are currently seeking solutions that not only visualize business processes but also automate them through the technical integration of various services. For an automated creditworthiness and fraud risk assessment process, various query and decision-making logics for creditworthiness and fraud are to be defined within a set of rules. It must be configurable to specify under which preconditions and in what order the queries are to be executed. Furthermore, return values and decision outcomes must be definable.
We have the following requirements for the Decision Engine:
Functional Requirements
The Decision Engine must accept data in real time, process it (run through the rule set), and return the respective result. In the rule set to be implemented in the Decision Engine, various query and decision-making logics have been defined that are based on the end customer’s query data, creditworthiness information, and proprietary data, such as blacklists and whitelists. This rule-based workflow is executed through individual if-then decisions. Depending on the result of an individual rule set, either the next rule set is applied, or the risk assessment process is terminated, and the determined return values are sent to the data interface of the upstream system from which the request originated.
On the one hand, the individual rule sets build upon one another; on the other hand, they must also be controllable independently of the specified order, so that individual rule sets can be flexibly skipped in the review process if they are irrelevant to the review. Conversely, depending on the review result of a rule set, further decision rules or rule sets must be triggered. Therefore, the Decision Engine must ensure that the stored standard rule set can be customized for specific merchants and that the individual rule sets can be linked together independently of the defined order. Rule sets must be duplicated, copied, and pasted.
The result of the creditworthiness and fraud risk check must be returned by the Decision Engine to the request source. The Decision Engine must therefore accept the request and creditworthiness data from the connected systems and databases, process this data, and return the result to the shop system or the PSP. The goal is thus to reach a positive or negative decision regarding an online order based on the stored rule set. Every transaction must be checked against the rule set. The rule set must be modified and expanded as needed. Consequently, the output data listed below must be modifiable depending on customer requirements. It must be possible to save intermediate results during the creation or modification of rule sets. Furthermore, modified rule sets must be transferable from a test system to the production system; the behavior of the rule set on the production system must not differ from that on the test system.
Modifiability
The rule set implemented in the Decision Engine must be configurable and fine-tunable by administrators at irregular intervals without affecting the production environment. Knowledge of a programming language must not be required at the administrator level.
Logging
The Decision Engine must log in a database, in a traceable manner for each transaction, which rules were applied and led to the respective decision. For each transaction, the response times of the respective process steps (interface activation, return of the result) must also be logged in log files.
System Availability / Downtime / Performance
System availability, provided the product is operated in an external data center, must not fall below an agreed-upon threshold.
System Stability Under Abnormal Data Conditions
The Decision Engine must be able to respond appropriately to any input (including seemingly nonsensical inputs) without crashing. User input errors must be detected and must not cause the system to crash. The user must be notified that an input error is occurring. High load spikes must not lead to a system crash.
Recoverability
Following a system failure or other disruption, we must be able to restore the system to its initial state within a maximum of 30 minutes and reinstate all implemented functions.
Fallback solutions, which may be necessary particularly after the implementation of new regulations or software updates, must be available.
Data Protection / Data Security
The Decision Engine must be adequately protected against unauthorized access that compromises data integrity, discloses confidential data, or impairs system availability.
Access to the rule set as a whole as well as to individual rule sets must be restricted to a defined group of individuals via an authorization concept that includes password rules.
All data processed in the Decision Engine, including input data, intermediate and final results, return values, and the rule set as a whole or in parts, must be protected against unauthorized access by third parties.
Compatibility
In the event of a version change, the Decision Engine must always be backward-compatible; that is, all system controls, parameterizations, settings, and rule sets from a previous version must be preserved even during version upgrades. During version changes, all system functions implemented up to that point must be preserved.
Reproducibility of Results
The system must be able to reproduce results once generated without modification at any time. That is, under identical conditions (input data, rule set version), no deviations from the original decision may occur when the credit check is performed again.
Multi-User Operation
Multiple users must be able to access the system simultaneously.
Multi-client capability
It must be ensured that multiple online stores with merchant-specific rule sets can be connected to the Decision Engine. Client-specific parameters and data must be logically separated from the parameters and data of other clients.
Note from SoftGuide
A detailed specification document is available and can be requested from us.
| Project statistics | Quantity |
|---|---|
| Selected solutions from our thematically relevant pool (900) | 23 |
| Solutions with high relevance according to corresponding feedback | 12 |
| Communication between SoftGuide and providers (emails, telephone) | 85 |