Run any Skill in Manus with one click

vendor-diligence

Stars0

Forks0

UpdatedMay 9, 2026 at 06:00

Drafts a second-line vendor diligence pack for a single ICT, fintech, cloud, data, or AI service provider. Captures inherent risk, criticality input, due-diligence evidence read against named regulatory criteria, residual risk, exit posture, and the gaps a control owner needs to close before onboarding or recertification. Handles AI vendors via an explicit AI-vendor branch in the same workflow. Best for: - A first-line owner has proposed a new ICT, fintech, cloud, data, or AI vendor and second-line needs the pre-onboarding pack. - A vendor risk team is recertifying an existing critical or important vendor and the prior pack is stale. - An AI vendor (foundation-model API, AI SaaS, embedded-AI feature, agentic system) needs diligence with the second-line lens, not a procurement checklist. - An exit-triggered or post-incident re-review of an existing vendor. Not the right tool when: - The criticality tier has not been set (run `criticality-assessment` first). - The job is portfolio-level concentration across m

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	vendor-diligence
description	Drafts a second-line vendor diligence pack for a single ICT, fintech, cloud, data, or AI service provider. Captures inherent risk, criticality input, due-diligence evidence read against named regulatory criteria, residual risk, exit posture, and the gaps a control owner needs to close before onboarding or recertification. Handles AI vendors via an explicit AI-vendor branch in the same workflow. Best for: - A first-line owner has proposed a new ICT, fintech, cloud, data, or AI vendor and second-line needs the pre-onboarding pack. - A vendor risk team is recertifying an existing critical or important vendor and the prior pack is stale. - An AI vendor (foundation-model API, AI SaaS, embedded-AI feature, agentic system) needs diligence with the second-line lens, not a procurement checklist. - An exit-triggered or post-incident re-review of an existing vendor. Not the right tool when: - The criticality tier has not been set (run `criticality-assessment` first). - The job is portfolio-level concentration across many vendors (use `concentration-risk-review`). - The job is contract clause coverage only (use `contract-gap-review`). - The vendor evidence is a published system card or model report and the question is "is this evidence pack sufficient for our deployment context" — that narrower question goes to `llm-vendor-evidence-review` in `ai-governance-model-risk`. This skill is the firm-side TPRM wrapper.
argument-hint	[arrangement: vendor name, service, criticality, deployment context]

Vendor diligence

A vendor diligence pack is what second-line produces so the named approver, head of TPRM, head of operational resilience, CISO, AI governance lead, business-owner SVP, can decide. The work is reading vendor evidence against the firm's regulatory and operational frame, separating what was inspected from what was claimed, and naming the gaps that have to close before onboarding or recertification. The skill stops at the recommendation. The approver decides.

This skill produces the pack as a markdown artifact (templates/default-output.md shape) and a structured record (schemas/vendor-diligence.schema.json) that downstream skills consume. Both onboarding diligence and the periodic recertification cycle use the same workflow; the AI-vendor branch flips on for any AI or AI-adjacent provider and surfaces a conditional ai_specific_findings block.

Ask first

Before drafting, get plain answers to four things. Most engagements answer them quickly; if not, default and flag.

What tier is the vendor. Sourced from criticality-assessment. Do not re-set it here. Tier drives diligence depth: a not-critical vendor gets a shorter pack; a critical vendor gets full depth with reviewer questions clustered for the relevant forums.
Is this AI or AI-adjacent. Treat as a boolean. The AI-vendor branch is a real branch, not a side-note: it conditionally surfaces ai_specific_findings and pulls the cyber and privacy overlays in by default. An embedded AI feature that is off is not AI-vendor mode; flag re-review on enablement.
What is the firm's regulatory profile. Institution type and primary regulators. Banking is not insurance is not capital markets is not payments-fintech. A dual-registrant or a fintech with a sponsor bank may need two sector overlays.
What is the engagement type. Pre-onboarding, annual recertification, off-cycle trigger, exit-triggered re-review, post-incident re-review, scope-change re-review. Each carries a different evidence-ask and a different decision-forum context.

When scope is supplied, the skill consumes it (institution type, sector overlay set, cross-cutting overlay set, persona, source posture). When it is not supplied, ask the four questions and default to public posture if the practitioner declines. Note in the pack that scope was not formalised; do not silently apply a default sector overlay.

How the pack gets built

The pack has the same spine across vendor types. A senior reviewer fills it in roughly in the order the engagement and the vendor offer evidence, not in a lockstep sequence.

The frame opens with the arrangement: vendor, service, criticality (read from criticality-assessment), the supported business process and, if the firm has an IBS map, the important business service. Data scope is named explicitly: NPI, PHI, PCI, customer prompts, model outputs, training data, logs. Data locations and any cross-border flows go here. The ai_vendor flag is set at the top; if true, cyber and privacy overlays are default-on for the rest of the pack regardless of how the scope cross_cutting_overlay_set reads.

Evidence collection is risk-based. The depth scales to criticality and review type. The standard ask is audited financials (or public filings, D&B, credit rating, runway disclosure for early-stage), SOC 2 Type II (full report, not the short-form summary), ISO/IEC 27001 certificate with the Statement of Applicability, current pen-test summary, vulnerability-management evidence (cadence, MTTR by severity, exception register), BCDR test reports with evidenced recovery objectives, the privacy program (data-processing register, sub-processor list, incident history), the sub-contractor and fourth-party register, and the regulatory and legal posture (sanctions, enforcement, litigation, registrations). For an AI vendor add the published system card or model report, the evaluation report, the red-team summary, the trust-and-safety pages, and the contract addenda on training-data use and abuse monitoring.

Reading the evidence is where the pack earns its keep. Each evidence area gets a status (sufficient, partial, missing, not-applicable) and a short note on what was actually inspected. SOC 2 scope and complementary user-entity controls matter, not just the opinion. Vendor RTO/RPO claims are claims; evidenced recovery objectives are facts. Both are read against the firm's impact tolerance for the supported important business service, not against the vendor's published commitment; the vendor's number is the ceiling, not the test. Region-pin promises are promises; data-residency reports are evidence. RFP narrative is not evidence. The pack cites by file path into references/source-anchors.md and the loaded overlays; it does not restate excerpts in the body.

The AI overlay, when ai_vendor=true, populates ai_specific_findings. The high-leverage items: system card fit to deployment (a system card describes the model on the vendor's benchmarks; it does not describe how the model performs on the firm's prompts, customer data, regulatory context, or downstream decisioning); eval coverage on the deployed system (the deployed system is base + fine-tune + RAG + retrieval + carrier-side guardrails, default false unless deployment-context evals are evidenced); training-data posture read from contract and trust-and-safety, not the marketing default, with the abuse-monitoring exception scope surfaced; shared-responsibility clarity on prompt-injection defence, retrieval quality, downstream-decisioning quality, and incident-response cooperation, which usually sit firm-side or shared; the prompt-as-customer-data lens, including HIPAA business-associate posture if PHI may appear in narratives; and the model-version pin and deprecation-notice clock, because the deployed checkpoint is a moving target. Agent-tool posture sits next to these for any agentic vendor: agent scope, tool whitelisting, sandbox guarantees, prompt-injection-via-tool-output, and the firm-side guardrails the deployment must add are read here even when the vendor's published evidence pretends the controls are vendor-side. Where the question becomes "is the vendor's published evidence pack sufficient for our deployment context", set eval_evidence_status = deferred-to-evidence-review, chain to llm-vendor-evidence-review in ai-governance-model-risk, record the linked record ID, and do not duplicate model-risk analysis in this pack.

The lifecycle cross-links close the pack. contract_gap_summary carries a one-paragraph headline plus a pointer to contract-gap-review (a diligence pack without a contract-gap pointer is incomplete). exit_plan_status points to exit-plan (a critical or important vendor without a current exit plan is itself a finding). concentration_flag points to concentration-risk-review (raise the flag here, do the portfolio analysis there). For AI vendors, ai_specific_findings.llm_vendor_evidence_review_record_id carries the model-risk evidence-review record where chained.

The pack ends with the recommendation: approve, approve-with-conditions, defer, decline, or escalate. Conditions are specific and verifiable. Open evidence gaps name what was asked, what was not received, and by when. Reviewer questions tie to the decision and cluster for the forum that decides: TPRM forum for an operational arrangement, risk committee for a critical vendor, AI risk committee for an AI vendor, fund board where the arrangement sits inside a registered fund. Name the decision checkpoints the pack must clear (scope, evidence, authority, impact, decision) and the conditions attached to each. The named approver decides.

Quality bar

Holds across every pack regardless of vendor type, audience, or render format. Every material claim cites a source from references/source-anchors.md (or a loaded overlay) by path. Unsupported claims are marked [evidence needed]. Section references that cannot be confirmed get [verify section] rather than fabricated. Source evidence, vendor management assertion, public-source obligation, generated inference, and open legal or compliance question stay distinguishable in the pack. No named institutions in narrative unless they are public defendants in a finalised enforcement action with a published consent order. The pack stops at the recommendation. RFP narrative is not evidence, anywhere.

Adaptation

Flexes by engagement. Pack depth and length scale to criticality and review type. Audience drives shape: a TPRM-forum pack reads short and operational; a risk-committee pack for a critical vendor reads longer with reviewer questions clustered for the forum; a fund-board pack reads differently again. Lead with the decision the audience must make. The sector overlay set drives which references/sector-overlays/<sector>.md is loaded; a dual-registrant or BaaS arrangement may load two. Cross-cutting overlay loading follows scope plus the rule that cyber and privacy default-on for AI vendors and for any vendor touching NPI, PHI, PCI, or important-business-service controls. Source posture (public-only, public-plus-firm-policy, public-plus-firm-policy-plus-system-of-record-evidence, connector-aware) drives the evidence ask. AI-vendor sub-fields differ by use-case category (foundation-model API, AI SaaS, embedded-AI feature, agentic system, RAG application, fine-tuned model, specialised classifier). Render format (Word, Excel, PowerPoint, Markdown) follows the workflow.

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 supervisory frame loaded per scope.
references/cross-cutting/cyber.md, privacy.md — cross-cutting flavour; default-on for AI vendors and for any vendor touching regulated data or IBS controls.
references/firm-overlay.md — firm-installed policy, taxonomy, decision forums and reviewer roles beyond the regulatory baseline; consumed when present.
templates/default-output.md — pack template.
schemas/vendor-diligence.schema.json — structured-output contract for downstream consumption.
examples/ — cloud IaaS for a regional bank's core deposit and loan platform; foundation-model API for a P&C insurer's first-notice-of-loss triage.
TROUBLESHOOTING.md — recurring pitfalls (system-card-as-substitute, retention defaults, eval coverage, prompts-as-customer-data, the boundary with llm-vendor-evidence-review).

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

The deliverable is the vendor diligence pack. Default to drafting against templates/default-output.md. Render as Word, Excel, PowerPoint, or Markdown when the audience or workflow asks for it (a TPRM-forum read may want Word; a multi-vendor review cycle may want a workbook; an AI-risk-committee read may want a deck). Produce the structured record at schemas/vendor-diligence.schema.json when downstream automation or a registered consumer needs it.

The downstream chain stays the same regardless of render format. contract-gap-review reads the contract-coverage findings via contract_gap_summary. exit-plan reads criticality, subcontractors, data_access, and the residual-risk read. concentration-risk-review reads the concentration_flag and the sub-contractor footprint. dora-register-builder reads the structured fields for ICT-third-party register entries where DORA applies. llm-vendor-evidence-review reads the linked record where eval_evidence_status = deferred-to-evidence-review.

When the structured record is produced, treat the schema as a downstream 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.