Regulatory reportingالتقارير الرقابية

Regulatory reporting is the files a licensed institution sends its regulator on fixed dates, describing its operations, balances and risks in a shape the regulator specifies rather than one it chooses.

A pretty dashboard does not replace a pack an auditor can open and understand without a week of questions. That difference, between the screen and the pack, is the whole of this topic.

Doing the work versus proving you did it

Suppose your screening control works perfectly. The system checks every new customer against sanctions lists, and not one case slipped through unchecked all year. Then the auditor arrives and asks something simple: prove it.

This is where a lot of teams fall apart. The checks really did run, but the records are spread across a database, an email thread, and a file on the laptop of someone who has left. The firm did the work and cannot demonstrate it, which to a supervisor looks the same as not doing it.

An entire product category exists for that reason. Its job is not to run the control. It is to assemble the proof that the control ran.

The evidence pack

That output is called an evidence pack (حزمة الأدلة). It is not a screenshot. It is a file tied to a defined period containing four things: what the control is, who owns it, what its results were during that period, and which exceptions occurred and who approved them.

Exceptions are the most important part and the part most often left out. An auditor is not looking for perfection. They are looking for awareness. A pack saying "the automated check failed on 14 cases, all handled manually within two days, approved by the risk manager" is far stronger than one saying everything was green all year. Because the second is either untrue, or it means nobody is looking.

The regulatory return

Different from the pack is the regulatory return (الإقرار الرقابي): periodic figures the authority asks for in a fixed format. Transaction volumes, complaint counts, operational incidents, and capital adequacy for the activity.

The difference between them is direction. You send the return on a fixed date. The pack is requested when an auditor decides to look. What they share is that both are the firm's obligation, and the tool eases assembly without removing responsibility for the number.

Reconcile before you file

The most dangerous step in that path is reconciliation. If the payment gateway says this month's transaction count was 410,000 and the accounting ledger says 409,000, you have a gap that must be explained before filing rather than after.

The cause is usually innocent. A transaction recorded after midnight landed in a different month in each system, or a reversal was counted once in one of them. But finding it from the auditor rather than from yourself changes the entire question. Instead of explaining a timing difference, you are explaining why you do not know your own numbers.

A simple technical rule follows: every pack needs a run id and a version number. If someone regenerates the report after a data fix, it must be visible that this is the second version and not the first. Otherwise two reports carry the same name and different figures.

How a pack is actually built

A pack is not assembled by exporting everything. That drowns an auditor without convincing them. It is built through control testing (اختبار الضابط): take a sample and prove the control worked on it.

Concretely: you onboarded 40,000 customers this quarter. Rather than attaching 40,000 records, you draw a random sample of fifty and show, for each one, when it was screened, against which version of the sanctions list, what the result was, and who signed it off. The sample must be random and the method documented. A hand-picked sample sinks the whole pack, because it proves you know where to look.

This needs something called data lineage (نَسَب البيانات), the ability to trace a number in the report back to its source. When the auditor asks where this complaints figure came from, "the quality dashboard" is not an answer. You need to walk from the number to the query to the table to the system that wrote the row in the first place.

Who asks for this in Saudi Arabia

Supervisors are not the only ones asking. The Saudi Central Bank may request payments data or operational incident reports. The CMA enters when the activity is investment, and the insurance regulator when it is insurance.

The fourth request comes from somewhere beginners overlook: the partner bank. A startup operating under a bank's licence is audited by that bank, and its requirements can be heavier than the regulator's, because the bank is risking its own licence. Raising transaction limits or adding a new customer segment usually goes through an evidence pack like this one.

Do not confuse monitoring with reporting

One vendor may sell you both, but they are different products. Monitoring produces daily alerts for an investigator to work, and is measured by response time. Reporting assembles proof for a closed period, and is measured by an audit passing without questions.

One can feed the other, so investigators' decisions become the material of the pack. But the buyer differs, the output differs, and the failure differs: the first fails by being late, the second fails when nobody can reconstruct what happened.