Engineering: integration, event model, and deployment
The integration effort lies not in how many endpoints you call, but in how well the event model fits your business. TruvaLI ingests the event and returns the score and decision: even non-monetary events follow the exact same path.
On the engineering side, the question is usually: how much work is it to fit this system into our existing flow? The answer depends less on the number of endpoints and more on how well the event model aligns with your business.
How does the core flow work?
Your application sends an event, the system evaluates it, and returns a result: the score, triggered rules, and the decision. The decision is returned fast enough to be used inline within the flow, because a delayed decision is no decision at all.
An event is not just a financial transaction. Logins, device changes, document uploads, setting changes, and account openings are also events, and they are used in rules in the exact same way. This distinction is critical in practice: patterns like account takeover and bonus abuse cannot be written without non-monetary events.
What should you consider in the data model?
| Topic | What it means |
|---|---|
| Data source isolation | Data from different products or subsidiaries is kept separate, and rules are scoped by source |
| Aggregation definitions | A customer's count, sum, and average within a period are pre-defined and referenced by name in rules |
| Rule versioning | The specific rule set and version executed are stored alongside the result of each event |
| Identity fields | Device ID, IP, email, and payment instrument are the fields used to build the relationship network |
| Decision logging | The original decision is stored, along with a change log if it is modified later |
Storing the rule version with the event is an audit requirement, but it is also useful from an engineering perspective: it makes it possible to trace which rule change caused a shift in behavior.
Do rule changes require deployment?
No. Rules exist as data, not code. This means compliance and fraud teams can modify rules without entering the engineering queue, permanently reducing the engineering workload. The structure of a rule is detailed on the rule and scenario engine page.
The impact of a rule change on historical traffic can be measured before going live; the rule simulation and backtesting page explains this.
Where does it run?
Deployment can be done on the organization's own infrastructure. This is not just a preference, but a regulatory requirement in certain sectors: data never leaves the organization, logs remain on your own systems, and the audit trail can be sent to a separate destination. Details are on the on-premise deployment page.
Authorization and access
The authorization model covers the maker/checker split, approval policies, multi-signature decisions, and delegation of authority. Access logs are kept immutably and can be written to a separate destination. Details are on the maker/checker, authorization, and audit trail page.
Where to start?
Usually, you start with a single flow: the point that causes the most losses or generates the most alerts. Events for that flow are sent, rules are run in simulation, and the results are compared with your existing system. If the comparison is satisfactory, the decision is integrated into the live flow.
The corresponding team perspectives are detailed on the fraud and risk and compliance teams pages.
Common questions
- How does the core integration work?
- Your application sends an event, and the system returns the score, triggered rules, and the decision. The decision is returned fast enough to be used inline within the flow.
- Are only financial transactions sent?
- No. Logins, device changes, document uploads, setting changes, and account openings are also events, and they are used in rules in the exact same way.
- Will data from different products get mixed up?
- No. Data sources are kept separate, and rules can be scoped by source.
- How are aggregations defined?
- A customer's transaction count, sum, and average within a period are pre-defined and referenced by name in rules.
- Do rule changes require deployment?
- No. Rules exist as data, not code; compliance and fraud teams can modify rules without entering the engineering queue.
- How do you find the source of a change in behavior?
- The specific rule set and version executed are stored alongside the result of each event, making it possible to trace which rule caused the change.
- Where is the deployment hosted?
- It can be hosted on the organization's own infrastructure. Data never leaves the organization, logs remain on your own systems, and the audit trail can be sent to a separate destination.
- Where is the best place to start?
- With a single flow that causes the most losses or generates the most alerts. Events for that flow are sent, rules are run in simulation, and the results are compared with your existing system.