Run any Skill in Manus with one click

exception-analysis

Stars0

Forks0

UpdatedMay 9, 2026 at 06:00

Classifies the deviations a control test surfaced into design gaps, operating-effectiveness failures, evidence gaps, scope disagreements, data-integrity issues, and anomalies; ranks severity with rationale; names a root-cause hypothesis; sets disposition (elevate to issue, close at exception, re-test, expand sample); and builds the handoff package downstream issue write-up consumes. Output is an exception register that pairs with the testing workpaper and ladders confirmed exceptions into the issue lifecycle. Best for: - A compliance-testing or internal-audit reviewer has finished sample testing and is sitting on a list of deviations that need to be classified before they become findings. - A QA reviewer is challenging a workpaper's exception treatment because the line between evidence gap and control failure was blurred. - A repeat-issue review needs to confirm whether deviations across testing cycles are the same root cause or coincidental. - A second-line lead is preparing a handoff to issue write-up and

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

anotb

anotb/second-line-financial-services

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Compliance OfficersBusiness and Financial Operations Occupations·SOC 13-1041

File Explorer

13 files

SKILL.md

readonly

More from this repository

same repository

fintech-partner-controls

anotb/second-line-financial-services

Drafts the fintech-side controls evidence pack a sponsor bank's third-party risk function expects in its file: control inventory mapped to Reg E error-resolution timing, NACHA Operating Rules obligations the program operator owes upstream, FBO subledger reconciliation, sponsor-bank reporting cadence, customer-facing disclosure adherence (Reg E §1005.7-§1005.11, Reg DD), money-transmitter / MSB BSA posture where applicable, contract-clause adherence evidence under the program agreement, and a 12-month incident-history summary. Output is a Word memo plus an Excel control inventory, review-ready for the fintech's own second line and for production to the sponsor bank's TPRM team or to a state-MTL examiner. Best for: - A fintech, neobank, BaaS program, or wallet operator preparing or refreshing its self-evidence pack for a sponsor-bank annual review, sponsor-bank-led audit, or state-MTL exam. - Compliance has been asked to self-evidence Reg E §1005.11 error-resolution timing (10 / 45 / 90-day clocks), NACHA retu

2026-05-090

agentic-ai-controls

anotb/second-line-financial-services

Reviews and proposes controls for an agentic AI use case (an AI system that selects actions, calls tools, reads or writes systems of record, or operates with autonomy beyond single-turn generation) in a regulated financial-services firm. Output names the agent's scope and authority statement, the architecture and tool inventory with permissions and blast radius, the identity and authorisation posture, the human oversight points with effective oversight evidence, the prompt-injection-via-tool-output and tool-misuse threat assessment, the kill-switch and rollback procedures with drill evidence, the logging and audit posture, the incident response with regulator-notification triggers, the residual risk with accepted owners, and the recommended owner actions. Designed for second-line review of agents that book actions in real systems, not chat-only assistants. Best for: - A first-line owner has built or is building an agentic system that calls tools, reads from systems of record, or executes actions, and second-

2026-05-090

ai-risk-tiering

anotb/second-line-financial-services

Assigns a defensible risk tier (tier-1 through tier-4) to an AI or model use case using a multi-factor rubric, and books the tier alongside the named gates and validation depth it triggers. The tier is the routing decision that drives validation depth, monitoring frequency, committee path, and vendor-diligence depth for the rest of model risk and AI governance. Best for: - An intake record exists and second-line needs to set the tier before sequencing validation, monitoring, or committee work. - A periodic re-tiering exercise on the AI inventory after a change in scope, autonomy, customer exposure, vendor, or supervisory posture. - A sponsor has proposed a tier and second-line needs to challenge or concur with reasoning that an examiner can read. Not the right tool when: - The use case has not been intaked yet. Route to `ai-use-case-intake` first; the tier decision is decided against an intake record version. - The question is whether the use case is high-risk under the EU AI Act specifically. Route to `ai-

2026-05-090

ai-use-case-intake

anotb/second-line-financial-services

Turns a first-line AI or model use case description into a structured intake record at the front of the AI governance pipeline. Captures purpose, intended users, data sources, vendor and foundation-model dependencies, autonomy level, decision impact, regulatory exposure flags, proposed review gates, and the open questions a tier reviewer needs answered. The intake is the routing artifact downstream skills consume: ai-risk-tiering reads it to score the rubric, ai-act-triage reads it to scope Annex III overlap, model-card-builder reads it for system and data sections, validation-plan reads it to scope work, and the AI inventory of record consumes the structured object. Best for: - A first-line owner has proposed an AI use case and second-line needs the intake on file before tier, AI Act triage, or any downstream artifact is scoped. - An AI inventory refresh requires consistent intake metadata across in-flight, in-production, and decommissioned use cases. - A vendor-supplied AI tool is moving from POC to limite

2026-05-090

board-ai-risk-pack

anotb/second-line-financial-services

Drafts the AI risk committee pack the AI Governance Lead carries into the meeting: AI inventory state with heat map by tier, top AI risks with trajectory, recent AI incidents and near-misses, foundation-model vendor concentration, model performance trends, GenAI program status, AI governance maturity posture, and the decisions the committee owes this cycle. The pack is the firm's standing instrument for AI-specific board oversight, alongside (not inside) the enterprise risk committee pack. Best for: - Standing AI risk committee meeting (often quarterly) where the AI Governance Lead, CRO, and head of model risk need a curated view of AI posture rather than the full inventory dump. - The AI section of a board risk committee at firms without a standalone AI committee, when the board wants AI-specific framing rather than a heat-map row inside the enterprise pack. - Board education session on AI governance: tier mix, top risks, foundation-model exposure, GenAI program status, and the decisions in flight. - Regula

2026-05-090

genai-pre-prod-review

anotb/second-line-financial-services

Pre-production gate review for a GenAI use case before initial release or material expansion. Pulls together the upstream artifacts (intake, tier, model card, validation-plan results, prompt-injection review where applicable, RAG evaluation review where applicable, vendor evidence review where applicable) and produces a recommended decision (go, go-with-conditions, hold, no-go) with reasoning, named blocking and tracking conditions, owners, and source trace. The artifact a senior risk officer or AI risk committee secretary signs into the gate meeting. Best for: - A GenAI use case is at the pre-prod gate and the second-line function needs the gate-review memo with a clear recommendation. - A material expansion of an existing GenAI deployment (new user population, new tool, new corpus, new geography) needs a re-gate. - A regulator pre-meet, examiner request, or supervisory motion is asking for the gate package on a named GenAI use case. - A recurring revalidation cycle has triggered a gate moment and the commi

2026-05-090

name	exception-analysis
description	Classifies the deviations a control test surfaced into design gaps, operating-effectiveness failures, evidence gaps, scope disagreements, data-integrity issues, and anomalies; ranks severity with rationale; names a root-cause hypothesis; sets disposition (elevate to issue, close at exception, re-test, expand sample); and builds the handoff package downstream issue write-up consumes. Output is an exception register that pairs with the testing workpaper and ladders confirmed exceptions into the issue lifecycle. Best for: - A compliance-testing or internal-audit reviewer has finished sample testing and is sitting on a list of deviations that need to be classified before they become findings. - A QA reviewer is challenging a workpaper's exception treatment because the line between evidence gap and control failure was blurred. - A repeat-issue review needs to confirm whether deviations across testing cycles are the same root cause or coincidental. - A second-line lead is preparing a handoff to issue write-up and wants the criterion, condition, cause, effect, and recommendation seed populated before the writer opens the issue artifact. Not the right tool when: - The test has not been run yet. Pre-fieldwork scoping is `test-plan-builder`; sample design is `control-sampling`; evidence asks are `evidence-request-builder`. - The exception has already been classified and the work is drafting the issue. Use `risk-compliance-core/skills/issue-writeup`; this skill produces the input that issue-writeup consumes via `source_exception_id`. - The work is drafting the workpaper end to end. Use `workpaper-drafter`; that skill consumes the exception register this skill produces via `exception_register_id`. - The work is QA on a completed workpaper. That is `qa-workpaper`.
argument-hint	[test plan ID, workpaper ID, raw deviation list, or pointer to completed sample testing]

Exception analysis

A control test produces deviations. Not every deviation is a finding. Some are evidence gaps the system did the right thing, the file did not record it. Some are anomalies a one-off mistake with positive evidence it does not recur. Some are design gaps the form, the workflow, the rule did not require what the criterion expects. Some are operating failures the design was sound, the operation missed. Some are data-integrity issues the system of record disagrees with the source feed. Some are scope disagreements the tester and the control owner read the criterion differently.

This skill takes the raw deviation list out of fieldwork, classifies each one, ranks severity with rationale, names a root-cause hypothesis, sets a disposition, and builds the handoff package the downstream issue write-up consumes. It drafts the exception register against templates/default-output.md and emits a structured record conforming to schemas/exception.schema.json. The workpaper drafter consumes that record by ID; the issue write-up consumes the per-exception handoff package via source_exception_id. The skill stops at preparer sign-off; the named reviewer signs separately and severity always carries human review.

Ask first

Before classifying, get plain answers. Most cycles answer them in the test plan and the raw deviation notes; if not, default and flag.

Whose register is this for. The testing manager closing the cycle, the QA reviewer challenging exception treatment, the issue-writeup author opening tracked findings, the internal audit lead deciding reliance, the examiner who reads the file later. Audience drives how heavily the rationale fields read and which dispositions get the most attention.
Has fieldwork actually finished. All sample items inspected, all procedures executed, walkthrough complete. A register built on partial fieldwork mis-projects deviation rate and mis-ranks severity. If fieldwork is open, route back to workpaper-drafter and stop.
What is the criterion the test was measured against. Pull it from the test plan and the workpaper's source criteria block. Classification turns on whether the condition deviates from the criterion or from the tester's reading of it; without the criterion in hand, scope-disagreement classifications cannot be defended.
Is there a prior cycle with similar deviations. A repeat-issue flag changes severity calibration and the issue-writeup handoff. Check the issue log for the same control or population before classifying; do not let "looks new" pass when the prior issue is still open.
What does the firm's tolerable deviation rate say. Pulled from the test plan. Aggregation reads against tolerable, not against the preparer's intuition. If the rate is unset, that is a test-plan defect to flag back, not a number to invent here.

When scope (per risk-compliance-core/scoping) is supplied, consume it: institution.type and institution.primary_regulators set the supervisory framing for severity rationale and dispositional language, sector_overlay_set selects which references/sector-overlays/<sector>.md loads, cross_cutting_overlay_set selects the references/cross-cutting/<topic>.md files, persona.role sets which decision forum the register passes through, source_posture constrains what the body can carry. When it is not supplied, draft against what the test plan and workpaper carry, default to the testing program's standing posture, and note in the register that scope was not formalised separately.

How the register gets built

The register has the same spine across control types. A senior preparer fills it in roughly in the order deviations surfaced, not in lockstep.

The header pins the register to its test cycle: exception register ID, test ID (foreign key into test-plan-builder output), workpaper ID (foreign key into workpaper-drafter output), control ID, obligation IDs, period under test, business unit, jurisdiction, source posture, preparer role and date, reviewer role and date placeholder. Reviewer separation is structural, not advisory: the same role cannot both classify and review classification. The header is the audit trail when classification is later contested in QA, in steering, or with a regulator.

Scope and source posture restates the test plan's scope in two or three sentences. The pointer to the workpaper goes here. If the workpaper noted scope changes from the plan, those carry forward into the classification context.

The exception register itself is the body. One row per deviation. For each:

Exception ID is stable across the engagement and feeds source_exception_id on the issue side.
Sample ID and population reference tie the exception back to the workpaper's sample-level results table.
Criterion names the rule, principle, policy section, or methodology the deviation is measured against, with a section reference and a pointer into references/source-anchors.md or the loaded overlays. "Per firm policy" without citation is not a criterion.
Condition is the dated, scoped, observable state. What the test actually saw. Specific. "On the 2026-Q1 access-recertification packet for the Production-Admin entitlement group, the per-entitlement attestation column was blank for 14 of 22 entitlements" is a condition. "The control failed" is a conclusion, not a condition.
Classification is one of: control-failure (design was sound, operation missed), design-gap (the design itself does not require what the criterion expects), evidence-gap (the system did the right thing, the file does not record it), scope-disagreement (the tester and the control owner read the criterion differently and the disagreement is not yet resolved), data-integrity (the system of record disagrees with the source feed or another authoritative system), anomaly (with positive evidence it does not recur). Classification is the load-bearing field; it drives severity, disposition, and what the issue-writeup handoff carries.
Severity is low, medium, high, or critical, paired with severity_rationale. Rationale references frequency (one-off, intermittent, recurring), customer impact (none, identifiable, quantified harm), regulatory exposure (no exam reference, ongoing exam scope, supervisory-finding-eligible), materiality against the firm's published thresholds where they exist, and any compensating controls. Severity without rationale is a number, not a finding. Severity assignment always carries human review.
Root-cause hypothesis is people / process / technology / data / governance, with a one-paragraph description naming the specific control attribute that failed. "Human error", "training gap", and "system limitation" are surface labels. The hypothesis names the design or operation weakness underneath. Where root cause is genuinely unknown at register time, the field reads "root cause analysis pending" and the disposition carries an open action; do not invent a cause to fill the field.
Repeat-issue flag and prior_issue_id. Check the issue log before flagging false. A repeat exception is a different severity calibration from a first-cycle finding.
Disposition is one of: elevated-to-issue (carries handoff package), closed-at-exception (with rationale, e.g., evidence re-supplied and reviewed), re-test-required (next cycle, with criteria for what closes the re-test), expanded-sample-required (with the expanded population and rationale).
Issue handoff package populates when disposition is elevated-to-issue. Carries criterion, condition, cause, effect (with unit and time window), and a recommendation seed. The package is the bridge into risk-compliance-core/skills/issue-writeup; that skill keys off source_exception_id and pulls these fields without re-discovering them.

Aggregation and projection compares observed deviation rate against the tolerable rate set in the test plan. The projection commentary reads anomaly versus systemic, names concentration in a particular segment or process or region or channel, and flags sample-design implications when the deviation rate suggests the population is not behaving as the sample assumed. The default posture is systemic; downgrading to anomaly demands positive evidence the deviation is non-recurring. Stratum-level breakdown belongs here when the sample was stratified.

Disposition summary clusters the register by classification and severity for the audience that decides next steps. How many design exceptions, how many operating, how many critical, how many evidence gaps closed at exception level, how many re-test items, how many elevated. The summary feeds the workpaper's exceptions-identified section directly.

The handoff to issue write-up names every elevated exception with its handoff package populated. Each elevated exception carries criterion, condition, cause, effect, and recommendation seed in the shape risk-compliance-core/skills/issue-writeup consumes. Where multiple exceptions roll up into a single issue (same root cause, different sample items), name the rollup grouping.

Reviewer questions captures everything that could not be resolved in classification or that the preparer wants the named reviewer to consider before sign-off. Cluster questions for the audience that decides them; severity calibration questions and root-cause questions go in the same list when both apply.

The sign-off block carries preparer, reviewer (separate role), and a confidence label (high / medium / low / unknown) reflecting evidence sufficiency, sample size, source posture, and any reliance on second-hand evidence. Source trace closes the file: every classification and severity rationale cites the criterion and the firm-overlay or source-anchor file path.

Sector and cross-cutting overlays

The same classification spine carries different criteria sources, different severity calibrations, and different reviewer machinery across sectors and cross-cutting topics. Load only the overlays the scope flags:

references/sector-overlays/banking.md carries large-bank supervisory-finding terminology context (the firm drafts in the same shape so its records align to examiner vocabulary; the firm does not invent a regulator-issued matter), heightened-standards severity flavour, and the BSA/AML and consumer-compliance exception conventions.
references/sector-overlays/insurance.md carries state DOI market-conduct exception conventions and the model-audit-rule severity framing for ICFR-relevant findings.
references/sector-overlays/capital-markets.md carries supervision-rule exception treatment for broker-dealer and investment-adviser testing, and enforcement-style language hygiene (the register concludes on control effectiveness, not on legal violation).
references/sector-overlays/payments-fintech.md carries sponsor-bank oversight exception conventions and Reg E error-resolution exception treatment.
references/cross-cutting/cyber.md is the most-loaded cross-cutting overlay. Cyber exceptions need careful classification because evidence gaps (no log) often look like control failures; the overlay carries the disambiguation pattern, IAM-recertification exception flavour, and incident-response control-effectiveness language.
references/cross-cutting/conduct.md loads when the test sampled a consumer-impact population. Conduct exceptions need consumer-harm framing distinct from technical control deviation; severity calibration shifts when customer harm is identifiable.

Privacy and climate cross-cutting overlays follow the same pattern; this skill ships cyber and conduct as the cross-cutting files because they are the most frequent triggers for exception classification. Where firm policy or taxonomy applies (severity ladder specific to the firm, named committee gates, policy-floor severity overrides for privileged access or critical data), it lives in references/firm-overlay.md and is consumed when present.

Quality bar

Holds across every register:

Every material claim cites a source. Mark unsupported items [evidence needed]. The register is the audit trail; absence of citation is a defect.
Source evidence, management assertions, public-source obligations, generated inferences, and open legal or compliance questions stay distinguishable in the register. The artifact shows the seams.
Classification is the load-bearing field. Default to control-failure for a deviation against an operating procedure and to design-gap for a deviation against the form or workflow itself; downgrade to evidence-gap only when the system shows the right thing happened, and downgrade to anomaly only when there is positive evidence the deviation does not recur.
Severity is paired with rationale. Severity assignment always carries human review.
The register concludes on control effectiveness and exception classification, not on legal violation. Legal-violation language is for legal counsel and regulator-led determinations.
Preparer and reviewer are different roles.
The skill stops at preparer sign-off. The named reviewer signs separately. The handoff to issue write-up is a draft until the reviewer attests and the issue is opened.
No named institutions in the register unless they are public defendants in a finalised enforcement action.

Adaptation

Register depth and length scale to deviation volume and severity range. A clean cycle with two evidence-gap exceptions reads short; a cycle with classified exceptions across multiple severities and root-cause categories reads longer with the disposition summary clustered for the audience that decides next steps. Sector overlay loading follows scope plus the rule that the regulator the test was designed for drives the sector overlay. Cross-cutting overlay loading: cyber overlay is default-on for any control test touching IAM, data-protection, or supervisory-rule-mandated security areas; conduct overlay is default-on for any consumer-facing test where customer-harm framing matters separately from technical control conclusion.

Pointers

references/source-anchors.md — citations and excerpts for the named anchors.
references/sector-overlays/banking.md, insurance.md, capital-markets.md, payments-fintech.md — sector-specific exception conventions loaded per scope.
references/cross-cutting/cyber.md, conduct.md — cross-cutting flavour; cyber default-on for IAM, data-protection, and security-rule-mandated controls; conduct default-on for consumer-facing populations.
references/firm-overlay.md — firm-installed methodology, taxonomy, severity ladder, named committee gates, and policy-floor overrides beyond the regulatory baseline; consumed when present.
templates/default-output.md — exception register template.
schemas/exception.schema.json — structured-output contract for downstream consumption.
examples/ — Reg E error-resolution exception classification at a regional bank; access-recertification exception classification at an entity under a state security-rule.
TROUBLESHOOTING.md — recurring pitfalls (treating every deviation as a finding, confusing evidence gap with control failure, skipping root cause, projecting anomalies, severity inflation, empty handoff packages).

The plugin-level shared references (references/source-map.md, references/policy-control-library.md, references/review-gates.md) sit at the plugin root and are consulted alongside the skill-level files.

Output

Default to drafting against templates/default-output.md. Render as Word, Excel, PowerPoint, or Markdown when the audience or workflow asks for it. Produce the structured record at schemas/exception.schema.json when downstream automation or a registered consumer needs it. Exception work is exception-log-natural: the real deliverable is an Excel root-cause matrix (one row per deviation with classification, severity, rationale, root-cause hypothesis, disposition, and handoff fields) paired with a Word findings memo carrying the disposition summary and the elevated-issue handoffs.

Downstream consumers: workpaper-drafter reads exception_register_id and pulls the classification summary into the workpaper's exceptions-identified section; risk-compliance-core/skills/issue-writeup keys off source_exception_id and consumes the per-exception handoff package (criterion, condition, cause, effect, recommendation seed) without re-discovering context; qa-workpaper reads the full record when reviewing exception treatment for sufficiency. The schema is the cross-skill contract; additive changes only. Add fields, do not rename or repurpose them. A breaking change is a versioned migration with the downstream skills told in advance.