Automating compliance in banks: from the rulebook to the reviewed measure

01 / Distributing tasks

Which compliance work can be supported with AI?

The suitable point of use is the preparation and organisation of work. A long rulebook can be broken down into units that can be worked on. Requirements can be linked to internal rules. A workflow records who has reviewed a proposal, confirmed a gap or taken on a measure. Quality depends on the transitions: a wrongly assigned document remains the wrong basis even in a workflow that is operated cleanly.

This article covers rulebook, requirements and measures management. Money laundering screening, transaction monitoring and the governance of the AI in use are other tasks with their own review subjects. Anyone evaluating compliance software for banks should therefore first name the workflow they need.

02 / One case, throughout

A work instruction is up to date. But who decides?

In sample case CASE-ORG-001 a fictional institution reviews its work instruction on handling internal rule changes. Version A requires tasks, decision-making powers and responsibilities to be defined. However, it remains unclear who reviews the need for change and decides on it. Another passage already regulates publication and version changes in a usable way. A promised decision record, by contrast, cannot be found in the material submitted.

Synthetic teaching case: all internal documents, roles, cases, dates and decisions are constructed. The case was not executed in a product installation. It is not a customer reference, not an official checklist and not evidence of full MaRisk coverage.

The close subject-matter reference is the MaRisk version of 30 June 2026: AT 5 deals with organisational guidelines, including responsibilities, currency and announcement; AT 6 with the documentation of material actions and determinations. For the example, an institution within the scope of application is assumed. Actual applicability must be checked at one’s own institution. [1]

From this reference we develop three review questions of our own. Their identifiers EXT-001 to EXT-003 are editorial aids. They are not statutory field numbers. The detailed roles, deadlines and acceptance rules in the materials are decisions made for the teaching case.

The evidence chain answers two different questions: What is required? and How can the internal implementation be assessed? Only the assessment connects the two. A list of measures without this way back explains what someone is to do, but not reliably why the task arose.

03 / Sources before proposals

Which version applies to the assessment?

An assessment needs a clearly determined source status. In the teaching case, POL-ORG-001-A applies from 1 September to 11 October 2026. Version B is approved on 9 October and takes effect on 12 October. The approval of B therefore does not retroactively change the basis of the assessment confirmed on 6 October, which is dated 5 October.

Before the derivation, the handler checks whether the document is complete, annexes are captured and the reference in the original actually matches the extracted text. For tables, cross-references or condensed sentences, checking a heading is not sufficient. The document extraction and the subject-matter review have different tasks here.

04 / Correcting proposals

From the clause to the verifiable requirement

A verifiable requirement describes a delimitable matter. It names the subject, the relevant reference and the basis on which the assessment is made. Several obligations in one sentence make the later decision harder: a passage can be partially covered even though the overall text sounds similar.

The first wording adds a rigid deadline and a blanket approval requirement that the excerpt used does not support. It is rejected. The second wording is our limited review question for the case; it does not yet lay down an individual approval process for every institution. [1]

The change is saved with a justification. This keeps it visible that the first proposal was erroneous and why the subject-matter version reads differently. Simply overwriting it would remove precisely this information.

Documented T-NEX process: In the manual, all clauses of a document version must first be approved before requirements can be derived from them. The subsequent subject-matter review of the requirements remains a separate step. Manual v15.23.0, chapters 4.6 and 5.3, pp. 19 and 22. [2]

05 / Comparing on subject-matter grounds

Text similarity is not evidence of fulfilment

A matching text hit shows where a review is worthwhile. Whether the internal rule covers the matter under consideration only emerges from content, responsibility and the state of the evidence. For the compliance gap analysis, a reasoned assessment is therefore more important than an isolated similarity score.

These three cases lead to different decisions. For ASM-001 a sufficiently concrete rule is missing. For ASM-002 the words match less closely, but the process under close consideration is described and evidenced in a traceable way. For ASM-003 the available evidence is not sufficient for a robust statement. A document missing from the review package does not, in itself, prove a breach.

The coverage of a rule and its performance in day-to-day practice are, moreover, separate levels. A published instruction can be complete while its practical implementation has not yet been reviewed. The assessment record therefore lists, alongside the internal requirement, the evidence used and the scope of the result.

“Partially covered” and “cannot be assessed” are editorial designations in the working materials here, not a commitment to particular selection fields in the product. The approval of an internal requirement confirms its recorded content; whether it is sufficient is decided only by the assessment.

T-NEX Compliance compares external requirements with approved internal requirements. For this purpose, internal source documents are likewise broken down via clauses and requirements. A free comparison of two PDFs does not fully describe this documented working path. Similarity, confidence, fulfilment status and severity must not be merged into a supposed hit rate. Manual, chapters 5–7. [2]

Open the product view in full size

06 / A decision becomes workable

Confirm the gap, approve the measure separately

The gap describes the identified difference between the review benchmark and the internal coverage. The measure describes how this difference is to be addressed. Both decisions need their own justification. A plausible remedy does not make an unsupported finding correct.

The data in the measure card are specifications of the synthetic case. 12 October is not a statutory deadline. In a real case, a responsible person is recorded by name or via a clearly attributable user ID.

The measure sheet links MEA-001 with GAP-001 and, via that, with EXT-001. The tasks concern the revision of the instruction and its announcement. The subject-matter assessment of whether the new process proves itself gets a separate review point.

The manual describes the approval of a gap and the approval of a measure separately. An AI proposal for a measures plan is initially a working draft. Manual, chapters 7.5 and 8.3, pp. 32–33 and 37. [2]

07 / Actually checking responsibility

Who may edit, who may approve?

A role name says little about which actions a user may actually perform. For the pilot case, the permissions are therefore checked against concrete steps: changing a requirement, editing an assessment, approving a gap, being accountable for a measure and issuing a report.

The matrix shows the desired organisational model of the teaching case. Product profiles and permissions of the specific installation must be set up and tested separately for this purpose. The product role of the same name, “Revision”, is not a description of all tasks of internal audit.

T-NEX Compliance supports different permissions for reading, editing and approving. According to the manual, however, one role can both edit and approve. A technically always-enforced four-eyes principle is therefore not evidenced. Manual, chapters 2.1–2.3, pp. 8–9. [2]

In the teaching case, internal audit does not approve any operational measure. Its independent review task remains separate from this. The MaRisk reference for this is AT 4.4.3; in the product, the manual at the same time describes a separate task of the “Revision” role in issuing audit reports. [1] [2]

08 / Keeping the status recognisable

Completed, effective and reported are different states

On 12 October, both tasks are completed in the teaching case: version B was introduced and announced. The planned review of a change case actually processed is still outstanding. It must remain recognisable to the reader whether a status display refers to task progress, a subject-matter assessment or a historical reporting status.

The product’s status logic is narrower: According to the manual, a gap is deemed remedied when all associated tasks are completed. No automatically evidenced effectiveness follows from this. The additional effectiveness review in the sample case is an organisational control step; a separate technical block for this is not evidenced. Manual, chapter 9.3, p. 39. [2]

A new source triggers a new question

When an internal policy changes, the handler must decide which requirements and assessments are to be reviewed again. In the case, this is the switch from A to B. The earlier assessment is not quietly relabelled as the assessment of the new version.

For a new external rulebook version, the manual describes a marking of the need for change. A corresponding automatic reassessment merely because an internal policy is switched is not evidenced. The pilot therefore tests the two events separately. For the external switch, N06 expressly uses fictional test versions; no further MaRisk amendment is claimed. Manual, chapters 7 and 10. [2]

An export is not an issuance. Only when an audit report is issued (“Issue report”) does T-NEX Compliance record the documented figures. A later export is the output of a report, not a new subject-matter confirmation. From this function alone, neither a qualified electronic signature nor any particular immutable archiving can be inferred. Manual, chapters 10.4–10.5, pp. 43–44. [2]

09 / Checking against your own process

What a limited pilot should demonstrate

A sensible pilot begins with a manageable, fully known set of documents. The team knows the expected references and deliberately builds in errors. This makes it possible to check whether sources and decisions remain traceable and how an incorrect assignment is handled.

Before the run, the product and model version, document scope, language, role permissions and configuration are recorded. The same prepared case is processed once with a complete basis and then with the defined deviations. Expectation and observation are kept in separate fields.

Execution status: The nine test cases are prepared but not executed in T-NEX Compliance. In the workbook, the actual results are therefore empty and the status reads “Not performed”. The completed subject-matter examples are not an acceptance record of a product run.

For its own pilot, the team can define in advance which errors prevent an approval and which corrections are acceptable. An untraceable source or an unjustified approval should be treated separately; an average across all tests would conceal such errors.

Anyone who wants to assess the effort measures the entire processing: preparation, AI run, subject-matter corrections, approvals and rework. Faster text output alone does not yet evidence an economic advantage. For the broader calculation, the article on the business case for GRC softwarehelps; for the switch from existing lists, the article on introduction from Excel inventories.

10 / Documented product functions

How T-NEX Compliance supports the process

T-NEX Compliance, formerly also called AI Compliance Hub, maps work with rulebooks, clauses, requirements, assessments, gaps, measures and tasks. The following mapping relies on the technical manual of 30 August 2026, application version 15.23.0. It describes documented functions, not an acceptance of the specific installation. [2]

For AI-supported requirements derivation, assessment, measures planning and report summary, a correspondingly set-up AI access is required. In the pilot, data paths, access permissions and the approved content of the actual installation must therefore also be clarified. Statements on data flows of other T-NEX products cannot be transferred to this without review.

The detailed product page on T-NEX Compliance explains the individual work areas. Supplementary product evidence and documentation statuses help with classification. For a broader selection process, the GRC selection criteria are available.

11 / The next decisions

What should still be clarified before use

What to do when internal rules are missing?

A missing internal instruction is initially a finding about the basis submitted. The next step is to clarify whether the rule exists elsewhere, has not yet been documented or is actually missing. The AI should not close this gap with an invented counter-requirement. A newly written instruction subsequently needs its own review and approval.

Is a link sufficient as evidence?

The link must lead to the right document and the appropriate version and be accessible to the authorised reviewers. The team should also be able to trace, after a change, which basis was used at the time. In the pilot, the content that the link actually opens is therefore checked; a green link icon is not enough.

Does the DORA register of information belong in the same process?

The register has its own data structure and a different processing purpose. A compliance requirement can refer to a corresponding process. However, that does not mean a register has yet been created or submitted. The separate article on the DORA register of information covers this task.

Is AI-supported compliance already AI governance?

Here, AI supports the processing of rulebooks. AI governance, by contrast, deals with the use and control of the AI itself. For the pilot described, accountability, approved use, data processing and control procedures for the use of AI must therefore additionally be clarified.