An automated pre-screen that reads a requirement and decides whether it must go through the IRA process — or reports what the requirement fails to say. Derived from IRA Checklist 3.
The IRA Checklist defines what gets reviewed once an initiative is already in IRA. It does not define what sends an initiative there in the first place. This page fills that gap with a working rule set, and states plainly which numbers in it are placeholders.
Of the checklist's 60 items, only the 8 under Business Sponsor → Risk identification have screening semantics. Those 8 are the rules below. The other 52 describe the review itself and are out of scope here.
Four values decide how this screen behaves. Three are proposed by Product and await Compliance sign-off. The fourth — the definition behind IRA-7 — does not exist yet, so that rule currently reports without triggering.
One rule firing is enough to route the feature to IRA. No second threshold, no weighting. Compliance may want a higher bar for some rules.
Customer reach above which IRA-5 fires, for features under a financial product (Credit, CashNow, Money, Collections, Lending, Acquiring, Quantix Risk…).
The same threshold for non-financial products (Core, Core CoE, Connect, AI, Open Platform). The business line is read from the ProductBoard hierarchy, never guessed by the model; anything unmapped defaults to the stricter financial threshold.
Revertable within 2 hours via remote config or server-side rollback, or IRA-6 fires. Note the consequence: a client change with no config switch can only be reverted by shipping a new build, which always exceeds 2 hours — so every such change triggers IRA. Compliance should confirm this is intended, or grant client releases a separate rule.
Without a definition IRA-7 cannot return NO. On technical and infrastructure work it fires on documented failure modes — reading a described fallback as evidence of risk — so it currently penalises the best-written requirements and is held out of the trigger set. On financial requirements it caused zero false triggers: every feature it flagged was already triggered by another rule. Proposed wording: a dependency is critical if its failure affects call setup, message delivery, login, or any movement of funds.
Each rule returns one of three values. The third one carries the weight.
A trigger is present in the requirement text, quoted as evidence.
The requirement affirmatively rules it out — "no new third parties", "UAE only under the existing licence".
The requirement is silent. Not a pass — an unanswered question, returned to the author.
Silence is never NO. A requirement that does not mention vendors is not a requirement without vendors. Allowing silence to clear a rule would make this screen produce a reassuring result from an empty document — which is the exact failure it exists to prevent.
Rolling up: any YES → IRA_REQUIRED. No YES but any
UNKNOWN → UNDETERMINED, with the list of what to add. All
NO → IRA_NOT_REQUIRED, meaning only that no trigger was found in the text —
never that Compliance has signed off.
| Rule | Fires when | Status |
|---|---|---|
| IRA-1 Third parties |
A vendor, partner, processor, external SDK or third-party API is introduced that is not already in production use. | Active |
| IRA-2 Data |
A personal or sensitive data type new to this product is processed, or existing data moves across a new border or to a new party. | Active |
| IRA-3 Regulatory |
A jurisdiction we do not already serve is targeted, or an activity falls outside the licence this product operates under. | Active |
| IRA-4 Financial crime |
A new money-movement path, funding or payout channel is created, or KYC / screening / limits / transaction monitoring change. | Active |
| IRA-5 Customer impact |
Customer-facing reach exceeds the threshold for the business line — 100/day financial, 10,000 communication. | Active |
| IRA-6 Reversibility |
Rollback takes longer than 2 hours, needs an app-store release, or the change is irreversible (migration run, notification sent, funds moved). | Active |
| IRA-7 Resilience |
A new dependency lands on the critical path — pending a definition of "critical path". | Reports only |
| IRA-8 Conduct |
Pricing, fees or customer-facing claims change, or the target segment may include vulnerable customers. Flags for review; never clears on its own. | Active |
Run read-only against all 68 released features on financial product lines (Botim Money, CashNow, EasyCash, SNPL, Acquiring, Quantix Risk, Collections, Salary Loan, Split Pay, SME Lending, WPS, Middle Service — plus unclassified products, which default to the financial threshold). Timeframes ending 31 Jul – 1 Oct 2026. Nothing was written back.
The 30 triggers hold up to review. No false positives were found in the list. The features tripping the most rules:
| Feature | Rules fired |
|---|---|
| Terrapay Integration | third party · data · regulatory · financial crime |
| Mastercard (Global provider) integration | third party · financial crime |
| ARP Digital Integration (India & Phil) | third party · regulatory · financial crime |
| Migration to ZAND VIBAN for merchants | third party · financial crime · reversibility |
| Credit card fee on checkout | financial crime · reversibility · conduct |
| SNPL — Risk Based Pricing (Phase 2) | financial crime · conduct |
| Cashnow RENEWAL Customer Tiering & Screening | financial crime · conduct |
Payment-rail integrations, cross-border corridors, card-scheme onboarding, pricing strategy and credit-risk rule changes — each one genuinely warrants a compliance look. Two rules carry most of the signal: IRA-4 (money movement) fired 16 times and IRA-8 (pricing and claims) 18 times, together 62% of all triggers.
Read the 55% correctly. It does not say those features are low-risk. It says their requirements do not contain enough information to judge risk at all.
Of the 68: 24 have a completely empty description and 42 are under 400 characters. The median is 195 characters.
Whether a feature can be decided tracks almost entirely with whether anything was written down. Requirements that triggered average 857 characters of description; those that could not be decided average 312 — barely a third as much.
So the constraint today is requirement quality, not the strictness of the compliance bar. That changes what to do about it: tighten the PRD standard, not staff up the review.
An earlier run over 30 randomly sampled features across all product lines gives a useful contrast — 30% triggered, 70% undetermined, 0% cleared. Two differences matter:
Split by business line, because the two behave differently.
In both cases the screen reports missing information back to the author from day one. That part needs no one's agreement and delivers value immediately.