Regtech

Technology enabled compliance, monitoring and regulatory reporting

Why this chapter matters

Regtech is sold as a way to make compliance cheaper. Sometimes it is. Sometimes it is a dashboard that produces a green tile while the underlying case is still a pile.

Sravanthi never hears the word. She feels it when an onboarding hangs on a screening hit nobody can clear, or when a report to a supervisor names a transaction she already disputed.

Ramesh lives in the queue the tool created. Gunaditya lives in the return the supervisor sent because the report could not be rebuilt.

This card is the operating idea. Digital compliance-by-design sits later in the module. Stay here on what the tool actually does, who owns the judgement, and what happens when the vendor is wrong.

The plain meaning

Regtech is software that helps a regulated firm meet an obligation: screen, monitor, evidence, report, or reconstruct.

It is not the obligation. It is not a defence by logo. The licensed firm still owns the outcome.

Common jobs:

  • identity and sanctions screening
  • transaction monitoring and unusual-activity cases
  • conduct and sales surveillance
  • prudential and regulatory reporting
  • policy mapping and evidence packs

If the tool cannot show why it alerted, or why it stayed quiet, you bought a siren with no note.

Regtech connects a defined obligation, relevant evidence, controlled decisions and a reconciled output.

Screening is a judgement with a vendor inside it

Name lists change. Transliteration fails. A hit on a common name is not a hit on your customer. Rules or models can support ranking and validated automated disposition; unresolved or consequential cases need the appropriate review. Retain decision context and relevant list versions. A previous false-positive clearance should not suppress new material information indefinitely.

Auto-clear rules are allowed if you can defend them. Auto-clear of anything the model finds "low" without a documented threshold is how sanctioned names sneak through a busy Friday.

Determine applicable sanctions and monitoring obligations from the actual jurisdictions, parties and activities. Set list-update, rescreening and escalation controls accordingly. OFAC publishes a US risk-based compliance framework; a vendor list does not automatically cover every applicable regime.

Monitoring that only produces volume is a cost centre

A rules pack copied from a vendor demo will drown Ramesh. Quality is closed-case outcomes, not alert counts. A high false-positive share needs investigation of base rates, thresholds, coverage and workload; it does not by itself prove low sensitivity. Evaluate missed events and confirmed outcomes as well as alert precision.

Typologies change. Mule patterns in digital onboarding are not the same as the old cash-heavy pack. The acquisition card already said bonus hunters live in free tiers. Monitoring has to know which product it is watching.

Reporting is a reconstruction job

A file that leaves the building must be rebuildable from the books you still hold. If the vendor warehouse is the only place the number exists, you do not have a report. You have a dependency.

Map each return field to its appropriate source and transformation, which may include ledger, risk, customer or transaction systems. When the source moves, the return owner is told before the next due date. Cloud and third-party cards later in the module will press this. Here the rule is: the supervisor will not accept "the tool changed".

Worked example: the onboarding freeze

In this fictional example, a new customer matches a list on a middle name. The journey freezes. No case owner. She retries four times and becomes four more alerts.

That is not careful screening. That is a missing desk. Staff the hit before you switch the rule on.

Worked example: the return that would not add up

In this fictional example, a transaction report totals to a number finance cannot find. The vendor counted authorisations. The book counted settled. Both teams are sure they are right.

Pick the definition in the product, not in the argument. Write it once. Use it in both rooms.

What usually goes wrong

Green dashboards, stale typologies.

Auto-clear nobody owns.

Alert volume used as a productivity badge.

Vendor model treated as the policy.

Reports that only exist in the vendor cloud.

A go-live that trains the tool on week one and never again.

Measuring what matters

Measure control coverage, stale inputs, false positives and missed-event evidence, aged referrals, decision quality, report completeness and reconciliation differences. Keep scope and denominators clear. A green dashboard or lower alert count does not establish that the underlying obligation is met.

What this card will not do

It will not pick your screening vendor. It will not write a rules pack. It will not file a return.

Which obligations you may automate, and what evidence a supervisor expects to see, are local. Check them against current primary sources.

Takeaway

Regtech is a tool for an obligation you still own. If the human cannot see the reason, and the book cannot rebuild the number, the licence did not get cheaper. It got quieter.

Regulatory posture on regtech

Identify the actual obligation and accountable entity, then validate how the tool supports it. Required lists, reporting definitions, deadlines and retained evidence differ by regime. Supervisory expectations and legal requirements should not be confused with a vendor configuration. Significant model uses need proportionate validation and ongoing review.

See also: Enterprise Risk Taxonomy · Mule Accounts and Account Networks

References and further reading

Continue to Digital Wallets.