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.
Some of these await Compliance sign-off; one — the definition behind IRA-7 — does not exist yet, so that rule reports without triggering.
The estimate threshold is not among them. It cannot send work to Compliance and cannot hide anything a requirement states; it only splits “cleared” from “ask the author”. It is a workload dial, set at 50 (30 for financial crime and conduct, which carry most of the checklist’s intent). At 50 a returned requirement has a median of 2–3 items to answer, against the 7–8 of the previous version that nobody acted on.
One rule firing on the requirement’s own words is enough to route it to IRA. An estimate never routes. 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.
Two tiers, and the split between them is about accountability, not confidence. What a requirement states is taken as written. Where it is silent, the screen estimates how likely the rule is to apply, given the kind of change it appears to be.
| The requirement says it | The requirement is silent | |
|---|---|---|
| Risk present | Flag to IRA goes to Compliance, with the quote |
Need more Info a question for the author |
| Risk absent | Cleared by IRA the author’s own declaration |
No action needed no reason found, nobody declared |
Only stated evidence reaches Compliance. A referral has to come with something a reviewer can read. “We estimate 40%” is not something anyone can act on, and a queue full of evidence-free flags teaches everyone to ignore the evidenced ones too. Measured across 210 requirements: letting estimates refer would have sent 544 of 665 to Compliance — 3.2× today’s load, 373 of them with no written risk at all. Referring on stated evidence alone holds it at 171, essentially unchanged, while still clearing 122 outright.
So inference may do exactly two things: clear a rule the text does not mention when the scenario makes it unlikely, and raise one as a question for the author. It may never refer, and it may never overturn what the text states.
| No description | Nothing is written. IRA Check stays
blank, which means “not screened yet” — what actually happened.
No action needed on an empty document would read as “we checked and found no
risk”. The screen re-runs once a description exists. |
|---|---|
| Under 200 characters | Stated answers only; no estimates. Below this the model extracts zero stated answers 61% of the time (93% at zero characters), against 16% above 600 — there is nothing there to infer a scenario from, and an estimate built on the product name alone is worse than an open question. |
| 200 characters or more | Both tiers. |
Silence is still never a pass on its own. An estimate can clear a rule, but the result is recorded as No action needed — the screen found no reason — never as Cleared by IRA, which is reserved for the case where the author wrote all eight answers down and can be held to them. Across 256 requirements screened, none reach that bar; the best manages seven of eight. The path is kept as the definition of “fully specified”, not as a working outcome.
Five kinds of work the IRA process does not cover at all, supplied by Compliance. This is not a restatement of the eight rules — it cuts across them. Rule 8 treats promotional claims as a trigger while EX-e exempts promotional campaigns outright, so before this existed the screen referred exactly the work that is out of scope.
| EX-a | Look and feel Visual or layout changes only — nothing about what the product does. |
|---|---|
| EX-b | Product information Presenting information about products, SO LONG AS it is not construed as sales. An upsell, cross-sell or acquisition surface is sales and is NOT exempt. |
| EX-c | Surveys and usage analytics Running surveys or collecting app-usage data, ONLY where that collection was already made clear during customer onboarding. A disclosure added later does not qualify. |
| EX-d | T&C updates Updating terms and conditions. |
| EX-e | Promotional campaigns Running a time-bound promotional campaign — a special rate for a week, a fee waiver for a limited period. Building a permanent promotional surface or product entry point is NOT this. |
The qualifiers carry most of the weight and are kept word for word. “So long as it is not construed as sales” turns on how a customer reads it, not on intent — an upsell or acquisition surface is sales however it is described. “Must have been made clear during customer onboarding” is past tense; a disclosure added later does not earn the exemption. And both promotional examples are time-bound: running a campaign is exempt, building a permanent promotional surface is not.
A stated risk outranks an exclusion. An exclusion applies only when the requirement states no risk. A week-long promotional rate is exempt; a promotion whose own text says it changes a fee has stated rule 8, and letting the exclusion win there would drop the one thing this screen exists to catch. Where they collide the stated trigger wins and the exclusion is reported rather than applied, so a reviewer can see it was considered and why it lost.
When an exclusion does apply, the verdict is No action needed and the
eight rules are not run. The follow-up names the exclusion and quotes the phrase behind
it — because “out of scope” and “we checked all eight and found
nothing” are very different claims about what was examined.
Provenance not yet recorded. Whether this list sits in IRA Checklist 3 itself or arrived as a later clarification is still to be confirmed, so that the basis for an exemption can be cited.
| 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.