Plain language rule writing
Plain language rule writing allows you to describe a risk scenario in your own operational language instead of technical syntax, converting it into an executable rule. In TruvaLI, the sentence you write becomes a parameterized draft rule that undergoes human approval.
Why is the IT queue a problem?
A compliance officer who spots a new fraud pattern usually knows exactly what needs to be done in seconds. However, they must wait for the software team to implement the rule: it takes days for a developer unfamiliar with compliance terminology to correctly interpret the scenario and write the code. During that waiting period, the institution remains vulnerable.
This is not a software capacity issue: it is a problem of authority residing in the wrong place.
An assistant that understands terminology
TruvaLI does not work like a simple word translator: it acts as an assistant fluent in compliance and risk terminology. A few examples:
"Generate an alert on the second transaction of minor users who have transacted 5,000 TL or more in the last week."
The system establishes the age < 18 condition from the term "minor", creates the >= 5000 threshold from "5,000 or more", defines the last 7-day window, and adds the transaction counter.
"Trigger a callback to our platform on the first transaction of foreign national customers if their last KPS check was more than 3 months ago." The system infers from "foreign national" that the ID number starts with 98 or 99 and the nationality is not TR. Instead of rejecting the transaction, it sets up an action to trigger a webhook to the core system.
Drafts do not go straight to production
The generated rule is a draft. It appears on the screen with its parameters: which fields, which thresholds, which window. You review and, if necessary, edit it. Then, you test it on historical data using rule simulation and send it for approval. The maker/checker workflow applies here as well.
The possibility of the system misunderstanding your sentence is mitigated by reviewing and measuring the rule before it goes live.
Report queries work the same way
The same approach works for reporting. Simply say, "List corporate customers who went to manual review this month but were flagged on our PEP list," and the system writes the SQL query.
What it delivers to the institution
- Same-day response to a new threat, right from your desk.
- Direct conversion of compliance knowledge into a rule, without intermediaries.
- Transparent and editable rule drafts.
- Software team capacity is freed from the compliance queue.
Common questions
- What happens if the system misunderstands my sentence?
- The generated rule does not go straight to production. It appears on the screen with its parameters, allowing you to edit it and simulate it on historical data. Additionally, going live is subject to an approval workflow.
- Which terms does it understand?
- Compliance and risk terminology: expressions such as age limits, ID number formats, activity codes, time windows, and amount thresholds are resolved from context. The term 'minor' converts into an age condition, and 'foreign national' converts into ID number and nationality conditions.
- Do we still need to write code for complex scenarios?
- Most scenarios do not require code. For advanced cases requiring custom calculations, there is an expression editor in the rule engine, but this is an additional capability rather than a necessity.