Show a supervisor how a decision was reached, without taking our word for it.
RegNovaIQ is a financial-crime risk platform with model governance in the decision path, not beside it. Every automated decision leaves a record: the model version that produced it, the policy in force, the rationale, and a reason code — retained as an artefact you can export and hand to a reviewer.
What this page states
- We publish our governance posture. We do not publish how our models decide.
- The artefact is disclosed in full. The method is not.
- RegNovaIQ is pre-revenue: no customers, no live client traffic.
- No third-party security certification is held. We hold no SOC 2 report. No SOC 2 examination has been completed.
The tension we design around.
Institutions that use automated risk decisioning carry the obligation to explain those decisions — to an auditor, a supervisor, and sometimes to the person the decision was about.
A vendor that cannot produce that explanation transfers its own opacity onto its customer's licence. We build so that the explanation exists before anyone asks for it.
Two things follow from that, and they are in tension. The evidence has to be complete enough to defend a decision. The mechanism has to stay closed, because detection logic that is published stops working. We resolve the tension the same way every time: the artefact is disclosed in full, the method is not. An explanation tells you what drove this decision. It does not tell an adversary how to avoid the next one.
Where we stand today.
We are stating this plainly because a compliance vendor that overstates its own posture has already failed the test.
- RegNovaIQ is pre-revenue. We have no customers and no live client traffic. Nothing on this page describes a production deployment at a financial institution.
- We hold no third-party security certification. We hold no SOC 2 report. No SOC 2 examination has been completed. We do not hold ISO 27001.
- We have not completed a conformity assessment and we carry no CE marking. For the categories in question the route would ordinarily be conformity assessment by internal control under Annex VI rather than a notified body — either way, it has not been done.
- The governance capabilities described below are built and exercised in our own environment. None of them is a roadmap item. None of them has yet run against a customer's production traffic, because we have no customers.
NOVAIQ LIMITED (company number 16948483, registered in England) is the company of record. RegNovaIQ is a member of NVIDIA Inception. Full statutory detail is on our company page.
Provider and deployer: who owes what.
The EU AI Act splits obligations between the provider of an AI system and the deployer who puts it to use. Most of what a supervisor will ask you about is a deployer obligation, and no vendor can discharge it for you. What a vendor can do is make it evidenceable.
| Obligation | RegNovaIQ (provider) | You (deployer) |
|---|---|---|
| Technical documentation | We produce the documentation set for the models we ship, structured to Annex IV. | You hold documentation for how you configured and used it. |
| Classification | We record how each system is classified and why. | You confirm the classification for your use, which may differ from ours. |
| Human oversight | We build the review points and record that a person acted. | You staff them with competent people and give them authority to override. |
| Logging | We generate the decision records and retain them. | You keep them for the retention period your regulator requires. |
| Affected persons | We supply a transparency report your end customers can be shown. | You decide what to disclose, to whom, and when. |
| Fundamental rights impact | We supply the inputs. | The assessment, where required, is yours. |
| Post-market monitoring (Art. 72) | A provider obligation where the high-risk regime applies. | You monitor your own use and tell us what you see. |
| Serious incidents (Art. 73) | We report on our side, and we tell you. | You report to your authority, and you tell us. |
| AI literacy (Art. 4) | Falls on both of us. We hold ours for our own team. | You hold yours for yours. |
The short version: we make the evidence; you make the decision and own the outcome.
One thing that moves the line
Under Article 25, a deployer that puts its own name or trade mark on a high-risk system, or substantially modifies it, becomes the provider and takes on the provider obligations in this table. If you intend to white-label or materially reconfigure, resolve that before you sign, not after.
Every model that can influence a decision is registered before it is deployed.
You cannot govern a model you cannot enumerate. The inventory is typically the first thing a supervisor asks for, and it is rarely the thing that already exists in one place.
The register is tenant-scoped: an institution's inventory is isolated from every other tenant's, enforced in the platform rather than by convention. Isolation is covered on our security page.
Each entry carries the model and its version, the business use case, the deployment stage, the intended users, the deployment context, a description of what the automated decision affects, whether human oversight is present, and the state of its training-data governance. Each registration is written as a tamper-evident record: a reviewer can establish independently that the entry in front of them is the entry that was created, and that it was not altered afterwards.
From the register, the platform generates a technical documentation pack structured to Annex IV of Regulation (EU) 2024/1689.
Checked against seven published frameworks and specifications
- EU AI Act technical documentation — Article 11 and Annex IV
- ISO/IEC 42001 — documented information for an AI management system
- NIST AI Risk Management Framework 1.0 — the documentation-bearing subcategories
- SR 11-7 — model risk management documentation elements
- GDPR Article 22 — automated decision-making disclosure
- Model Cards for Model Reporting
- Microsoft Responsible AI Standard v2
Here is the exception to that claim, and it matters. A documentation check can only prove a documentation obligation. Article 11 and the Model Cards specification define documents, so a check against them can reach a compliant verdict. The other five impose organisational and process obligations that no stored document can evidence. Those requirements are marked not evaluable, and they cap the result at partial. We would rather show you a ceiling than a green tick that does not mean anything.
Explanations, retained as artefacts.
An explanation is produced at the point the decision is made and stored with it. It is not reconstructed afterwards, and it is not a template with values dropped into it — each explanation is specific to the decision it belongs to.
Each explanation is retained as a structured artefact containing the decision, the model version, the policy context, the rationale recorded at the time, a reason code, and a natural-language summary. It is exportable and tenant-scoped.
Two properties are worth stating exactly.
- The platform does not synthesise an explanation. Where it cannot produce a genuine one, it records that it could not, and why. It does not emit a plausible substitute.
- For decision classes you designate as consequential, an unexplainable decision does not ship. It is blocked and routed to a person instead. The alternative — issuing a decision no one can account for — is the failure mode this control exists to prevent.
We do not publish the attribution method, the model architecture, or the factors themselves. Those are the mechanism.
Drift and fairness monitoring.
Monitoring runs on three cadences, and which one applies depends on the check.
- Continuous, on the decision path. Explanation generation and decision recording happen inline. They are not a batch job.
- Scheduled. Drift detection, fairness evaluation, and model documentation regeneration run on schedules configured per model.
- Event-triggered. A detected drift event can raise an alert and open a retraining request immediately, rather than waiting for the next scheduled run.
Fairness monitoring produces a report per model with a retained history, so a reviewer can see the trajectory rather than a single snapshot. Drift events are recorded with their outcome — triggered, or not triggered and why — and retained as tamper-evident records.
We publish no metric values, no thresholds, and no band boundaries. A fairness number without its population, its date and its definition is not evidence, and a threshold in public is a specification for evading it.
Retraining is a governed event, not a background convenience.
A retraining run can be requested by a person or triggered by a detected drift event. Either way it enters the same path: the new version is registered, validated, and put through an approval workflow with a recorded decision before it can be deployed. Approvals sit in a pending queue with an owner. Deployment is a separate, recorded step from approval, and each deployment carries its own record and its own monitoring.
The lineage between versions is retained. So is the audit trail of who approved what, and when.
The control a supervisor actually asks about
On the platform, no model version reaches a decision path without a recorded human approval. That is the control, and it is enforced in the deployment path rather than asked for in a policy document. It is also the answer to the question a supervisor actually asks, which is not “is your model good” but “who signed it off”.
The four points where a person is required.
All four are recorded.
- Model approval. A version is approved by a named person before deployment. Recorded in the model registry.
- Unexplained consequential decisions. Blocked and routed to review rather than issued. Recorded on the decision.
- Alert and case disposition. An analyst dispositions the case. The system produces the evidence; the person makes the call. Recorded in the case record.
- Autonomous agent actions. Every material action taken by a RegNovaIQ Autonomous Compliance Agent (RACA) stays behind a human approval boundary. It cannot execute on its own authority.
Human oversight is also recorded as a property of each registered system, so its presence or absence is a fact in the inventory rather than an assurance in a slide.
High-risk classification: our position.
The EU AI Act (Regulation (EU) 2024/1689, Official Journal text) entered into force on 1 August 2024 and applies in stages.
Our position on classification is this. We do not assert that our platform sits outside Annex III. Four things make that assertion unsafe for anyone to make on your behalf.
- Annex III point 5(b) covers AI used to evaluate the creditworthiness of natural persons with an express exception for systems used to detect financial fraud. That exception is real and it is narrow. Whether a given deployment falls inside it is a question about your use, not about our code.
- Article 6(3) allows an Annex III system to escape high-risk status where it poses no significant risk of harm. That derogation does not apply to a system that profiles natural persons. Risk-scoring individuals is profiling. A deployer should assume the derogation is unavailable until advised otherwise.
- Classification follows the deployer's purpose. Two institutions running the same configuration for different purposes can land on different sides of the line.
- Under Article 25, white-labelling or substantially modifying the system moves you from deployer to provider, and the obligations move with you.
So the platform does not decide the answer for you. It gives you the register to record the classification, the evidence to defend it, and the Annex IV pack to document it — whichever way it lands.
Separately, GDPR Article 22 bites where a decision is solely automated and produces legal or similarly significant effects. If you place a person in the decision, that is a fact you need to be able to prove. The platform records it.
What you can evidence to a regulator.
Each artefact below answers a question a supervisor actually asks, in the form they ask it.
| Artefact | What it contains | What it answers |
|---|---|---|
| Model inventory | Every registered model, its version, use case, oversight state and classification | “What AI are you running?” |
| Annex IV documentation pack | The technical documentation set, generated from the register | “Show me the technical documentation.” |
| Model card | The model's documented description, checked against seven published frameworks, with a stated ceiling where a requirement cannot be evidenced by a document | “What is this model, and what are its limits?” |
| Decision explanation | Per decision: model version, policy context, rationale, reason code | “Why was this customer treated this way?” |
| Fairness report and history | Per-model evaluation with a retained trajectory | “How do you monitor for bias?” |
| Drift record | Detected drift, outcome, and whether retraining was triggered | “How do you know it still works?” |
| Approval and lineage record | Who approved which version, when, and what preceded it | “Who signed this off?” |
| Deployment record | Which version went where, and when | “What was live on the date in question?” |
| Transparency report | A plain-language statement of automated decisioning and data-subject rights, for your end customers | “What did you tell the people affected?” |
| Audit trail | Action-level record of privileged and governance actions | “Was any of this changed after the fact?” |
Registrations and reports are tamper-evident: the record carries what a reviewer needs in order to establish that the artefact that was produced, without having to trust us or the platform to say so.
What remains your responsibility.
We will not describe these as things the platform handles. They are not.
- Classifying your own use and recording the reasoning behind it.
- Deciding whether to act on a risk output. The platform produces evidence; your policy and your people produce the decision.
- Staffing human oversight with people who understand the system and have authority to override it.
- Retaining records for the period your supervisor requires. The Regulation sets a floor for deployer log retention under Article 26(6); your sector rules may set a longer one. Retention on the platform is configurable.
- The fundamental rights impact assessment under Article 27, where it applies to you.
- Informing affected persons and workers, where required.
- AI literacy for your own staff.
- Input data you control — relevance and representativeness of what you send us.
- Serious incident reporting to your authority, and to us.
- Your own DPIA and lawful basis under GDPR.
What we do not claim.
- We do not claim a certification we do not hold. We hold no SOC 2 report. No SOC 2 examination has been completed. ISO 27001 is not held.
- We do not claim a conformity assessment or a CE marking.
- We do not claim customers, production deployment, or live client traffic. We have none.
- We do not publish accuracy, false-positive or fairness figures. With no customer deployments there is no denominator, and a performance number without one is fiction.
- We do not claim that our documentation check proves compliance with any of the seven frameworks. It proves a documentation obligation, and only where the framework defines one.
- We do not claim that using RegNovaIQ makes you compliant. It makes your position evidenceable. Compliance remains a finding about your institution, made by your supervisor.
- We do not publish our detection logic, model architecture, features, thresholds, or the sources behind our intelligence.
Documents, and how to get them.
The documents we can point you to today are public, and they are listed below. Anything beyond them is handled by request, and where an NDA applies we will say so before you start rather than after.
| Document | Access | Status |
|---|---|---|
| Architecture and security whitepaper | Public | Read the architecture and security whitepaper |
| RACA governed-autonomy whitepaper | Public | Read the RACA whitepaper |
| SOC 2 Type II report | — | Not available. We hold no SOC 2 report. No SOC 2 examination has been completed. |
For anything not listed above — sample artefacts, model governance material, or contractual documents — email contact@regnovaiq.com and we will tell you what we are able to share and on what terms.
Questions we get asked.
Is RegNovaIQ a high-risk AI system under the EU AI Act?
That depends on your use, and we will not answer it for you. Annex III point 5(b) expressly excepts financial-fraud detection from the creditworthiness category, but Article 6(3)'s escape route is closed to any system that profiles natural persons, and Article 25 can make you the provider rather than the deployer. The platform gives you the register and the documentation to record and defend whichever classification applies.
Can you explain an individual decision after the fact?
Yes. The explanation is generated with the decision and retained with it, along with the model version and the policy that was in force at the time.
What happens if the system cannot explain a decision?
It says so, and it says why. For decision classes you designate as consequential, the decision is blocked and sent to a person rather than issued unexplained.
Will you tell us what drives a score?
An individual decision arrives with its rationale and reason code, and that is what a supervisor and a data subject need. We do not publish the feature set, the model architecture, or the thresholds. Those are the mechanism, and a published mechanism is an evadable one.
Do you have customers we can speak to?
No. We are pre-revenue with no customers. We would rather you heard that here than found it out later.
Talk to us before you need to.
If you are evaluating automated decisioning against a supervisory deadline, the useful conversation is the specific one: your classification, your oversight design, and what your regulator has actually asked for.