In the financial sector, risk management is abundant with decision rules. Years of business experience, compliance requirements, and historical risk events have established numerous evaluation frameworks. What banking and insurance institutions truly need is a mechanism to ensure these rules operate reliably within real-time processing pipelines.

Large-value transfers should be intercepted in seconds, yet they often await batch processing; post-password-change transactions, brute-force login attempts, and multiple claimants from the same incident require immediate flagging but necessitate complex system modifications; frequent rule adjustments demand code changes, redeployment, and retesting, ultimately discouraging necessary updates.

Many high-value risk scenarios aren't inherently complex—their logic can be clearly expressed through rules: single large-value transfers, frequent small-value splitting over 24 hours, geographically anomalous transactions within an hour, consecutive password failures within 30 minutes, multiple loan applications within 30 days, claims filed within 90 days of policy issuance, and more than three related claimants from the same incident. The critical requirement for these rules isn't complexity, but real-time execution, stability, modifiability, and interpretability.

We've implemented a comprehensive risk control framework for banking and insruance scenarios, successfully testing the complete pipeline in Easysearch 2.1.2. This documentation serves as a reference for similar implementations.

Key Results

• Rule Count: 24
• Coverage Areas: Banking transactions, anti-money laundering, account security, credit risk, insurance claims
• Rule Compilation Time: 415ms
• Individual Rule Validation: 24 / 24 matches
• Mixed Business Flow Test: 8 samples, 6 matches, 2 non-matches (legitimate events)

Post-processing outputs structured risk fields including match status, matched rule IDs, match count, and maximum risk level. Downstream systems can directly utilize these fields for decision-making without additional parsing.

Rule Engine's Role in the Pipeline

This architecture divides the entire pipeline into three layers: upstream feature systems handle window aggregation, account profiling, list matching, and relationship features; Easysearch rule engine manages real-time matching and structured output; downstream处置 systems handle interception, secondary verification, manual review, and alert notifications.

The rule engine doesn't perform historical aggregation. Fields like acct_txn_cnt_24h (transaction count within 24 hours), loan_apply_org_cnt_30d (application institutions within 30 days), and txn_geo_distance_km_1h (geographic distance within 1 hour) are pre-calculated by upstream stream processing or feature services and stored as flat fields in the current event document. The rule engine's responsibility is to transform "current event + pre-calculated features" into risk results.

This clear delineation establishes boundaries for rule maintenance and engine functionality.

Breaking down this real-time risk control pipeline reveals five core steps: event ingestion, feature enrichment, rule compilation, online matching, and result output with处置. The following diagram illustrates the complete workflow for banking and insurance scenarios.

Five Risk Scenarios Covered

ScenarioExample RulesBanking TransactionsLarge-value transfers, late-night large-value transfers, new account large-value outflowsAnti-Money LaunderingSmall-value splitting, fund aggregation followed by transfer, dormant account activationAccount SecurityBrute force attacks, credential stuffing, immediate post-password-change transfersCredit RiskMultiple loan applications, sudden balance drops before payment dates, excessive income-to-debt ratioInsurance ClaimsClaims shortly after policy issuance, frequent small-value claims, multiple related claimants from same incident

A portion of the rule file appears below:

event_type{{txn}} and biz_line{{bank}} and txn_type{{transfer}} and txn_amount{r{50000,}}	T01|HIGH|bank|Large transfer triggered
event_type{{txn}} and biz_line{{bank}} and acct_txn_cnt_24h{i{10,}} and txn_amount{r{,9999.99}} and acct_txn_sum_24h{r{50000,}}	T02|HIGH|bank|Frequent small-value splitting within 24h
event_type{{login}} and biz_line{{security}} and login_pwd_fail_cnt_30m{i{5,}}	S01|HIGH|security|Excessive password failures within 30m
event_type{{loan_apply}} and biz_line{{credit}} and loan_apply_org_cnt_30d{i{3,}}	C01|HIGH|credit|Multiple loan applications within 30d
event_type{{claim}} and biz_line{{insurance}} and accident_related_claimant_cnt{i{3,}} and accident_relation_flag{{1}}	I03|HIGH|insurance|Multiple related claimants from same incident

The critical aspect isn't the syntax, but the input document structure. Rules don't match raw transaction logs but feature-processed event documents. For instance, the following sample includes pre-calculated 24-hour statistical features:

{
  "event_type": "txn",
  "biz_line": "bank",
  "acct_txn_cnt_24h": 12,
  "txn_amount": 9999.99,
  "acct_txn_sum_24h": 60000
}

This document should match rule T02. By calculating features upstream and performing real-time matching in the engine, this approach ensures practical implementation.

Multi-Rule Match Verification Results

In real-world risk management, a single event often triggers multiple rules. Our mixed sample validation constructed test cases closer to actual business flows:

Document IDMatched RulesMaximum Risk Levelbank_multi_1``T01, T04, T05, T06``HIGH``aml_multi_1``A01, A02, A03``HIGH``security_login_multi_1``S01, S02, S03, S05``HIGH``security_txn_1``S04``HIGH``credit_multi_1``C01, C03, C03B``HIGH``insurance_multi_1``I01, I02, I03, I04, I05``HIGH``safe_bank_1No matchesNonesafe_login_1No matchesNone

These results provide greater practical reference than individual rule validations, demonstrating stable output in mixed business flows and correct identification of legitimate events.

Output Result Format

Matching outputs extend beyond simple tagging. The following shows actual results for a large-value transfer sample after processing:

{
  "risk_tags": [
    "#0#T01|HIGH|bank|Large transfer triggered",
    "#4#T04|MEDIUM_HIGH|bank|Late-night first-time counterpart large transfer",
    "#5#T05|HIGH|bank|New account large outflow on same day",
    "#6#T06|LOW|bank|Round amount preference with new counterpart"
  ],
  "risk_repo_id": "fintech_risk_20260415_demo",
  "risk_matched": true,
  "risk_hit_count": 4,
  "risk_rule_ids": ["T01", "T04", "T05", "T06"],
  "risk_levels": ["HIGH", "MEDIUM_HIGH", "HIGH", "LOW"],
  "risk_level_max": "HIGH",
  "risk_biz_lines": ["bank", "bank", "bank", "bank"],
  "risk_titles": [
    "Large transfer triggered",
    "Late-night first-time counterpart large transfer",
    "New account large outflow on same day",
    "Round amount preference with new counterpart"
  ]
}

Non-matching output:

{
  "risk_repo_id": "fintech_risk_20260415_demo",
  "risk_matched": false,
  "risk_hit_count": 0,
  "risk_rule_ids": [],
  "risk_levels": [],
  "risk_biz_lines": [],
  "risk_titles": []
}

Downstream systems can directly use these fields for decisions: when risk_matched is true, trigger risk control workflows; when risk_level_max is HIGH, implement interception or route to high-priority queues; risk_rule_ids and risk_titles support audit trails and manual review interfaces.

Integration with Easysearch

Resources used in this validation:

Resource TypeNameRule Repositoryfintech_risk_20260415_demoIngest Pipelinefintech_risk_demoIndex Templatefintech_risk_events_demoDemo Indexfintech-risk-events-demo-2026.04.15

The complete pipeline path: import rules to rule repository → compile rules → create index template with default pipeline → upstream writes feature-processed event documents to business index → downstream reads structured risk fields for处置.

Two prerequisites must be ensured: the rule repository must be _compiled before use, and required feature fields must be prepared before business writes.

Writing directly to the index triggers processing:

POST /fintech-risk-events-demo-2026.04.15/_doc/bank_multi_1

The index template includes a default pipeline:

{
  "index.default_pipeline": "fintech_risk_demo"
}

The corresponding pipeline logic is straightforward: execute rule matching first, add repository identifier, then expand matched tags into structured risk fields. A simplified definition follows:

{
  "processors": [
    {
      "check_match_rules": {
        "rules_id": "fintech_risk_20260415_demo",
        "match_field": "risk_tags"
      }
    },
    {
      "set": {
        "field": "risk_repo_id",
        "value": "fintech_risk_20260415_demo"
      }
    },
    {
      "script": {
        "lang": "javascript",
        "source": "Parse risk_tags into structured fields: risk_matched, risk_hit_count, risk_rule_ids, risk_level_max"
      }
    }
  ]
}

No additional ?pipeline= parameter is needed. Upstream calls remain simple—integration points don't need awareness of the rule engine, as matching capabilities are embedded within the write pipeline.

Why This Approach Suits Banking and Insurance

Banking and insurance scenarios share common characteristics making rule engines particularly suitable for underlying real-time risk control:

Large-value transactions, late-night activities, short-term claims, and frequent filings have clear thresholds rather than模糊 signals. The primary concern isn't detection capability but timeliness.

Regulatory changes, business process adjustments, and emerging fraud patterns continuously drive rule modifications. If each rule change requires code modifications and redeployment, system iteration cannot keep pace with business evolution.

Banking and insurance decisions often require review, traceability, and audit trails. Rule-based results offer inherent interpretability—identifying which rule triggered, risk category, and maximum level—providing much clearer information than logic scattered across code and ETL scripts.

A Practical Recommendation

Not all risk control should be model-based. In banking and insurance scenarios, a more stable architecture involves: upstream systems handling window aggregation and profiling, Easysearch rule engines managing real-time matching and structured tagging, and models addressing more complex,模糊 risk patterns.

Rule engines aren't model replacements but the foundational layer that should first be implemented in real-time risk control pipelines.

If you're implementing banking or insurance risk control, start by extracting 10-20 representative rules, incorporate existing aggregated features into event documents, and run a rule import, compilation, and sample validation cycle on Easysearch. After completion, you'll understand how much existing risk logic can be extracted from code and which risks can be quickly addressed through rules.

The rule engine functionality currently requires a trial license. You can download Easysearch: https://infinilabs.cn/download, then contact sales to request a trial license and implementation guidance.