fsi-compliance-checker – skill Lập trình cho agent AI

FSI Compliance Checker

Overview

Maps a concrete change (code diff, architecture design, IaC, pipeline config) to the specific controls it touches in financial services compliance frameworks — PCI-DSS v4.0.1 for payment card data and MAS TRM for Singapore-regulated institutions — and reports gaps with actionable remediation. This is engineering-level compliance triage: it helps teams catch violations before audit, but it does not replace a qualified assessor (QSA) or the institution's compliance function. Say so in every report.

When to Use This Skill

• Use when a change touches payment card data (PAN, CVV, track data) and needs a PCI-DSS check
• Use when reviewing changes at a Singapore-regulated financial institution against MAS TRM expectations
• Use when someone asks "is this compliant", "does logging this violate PCI", or requests a banking-regulation review of a diff, design, or Terraform change
• Do NOT use for generic security review (no framework involved), GDPR/SOC2/HIPAA (out of bundled scope), or legal advice

How It Works

Step 1: Select the framework

Load only the reference file(s) the engagement needs:

| Situation | Load |

|-----------|------|

| Payment card data is stored, processed, or transmitted | [pci-dss.md](pci-dss.md) |

| Singapore-regulated financial institution (bank, insurer, capital markets, major payment institution) | [mas-trm.md](mas-trm.md) |

| Both apply (e.g. Singapore bank handling cards) | Both files |

| Other jurisdictions/frameworks (SOX, GDPR, HKMA, APRA) | State they are out of scope; offer general secure-engineering review instead |

If the user hasn't said which applies, ask one question: what data does the change touch, and is the institution Singapore-regulated?

Step 2: Scope the change

Identify what the diff/design actually touches: data elements (card data? customer PII? credentials?), trust boundaries, environments (production? DR?), and third parties.

Step 3: Assess applicable controls

Select the applicable controls from the loaded reference file(s) — typically 5-15 controls, not the whole framework. List what you ruled out and why (one line each) so the scoping is auditable. Assess each as Supported by reviewed evidence / Gap / Needs evidence (can't tell from the artifact — name the evidence required).

Step 4: Report

Every Gap gets: the control ID, what's wrong in this specific change, concrete remediation, and severity (Critical = violation involving live regulated data; High = control absent; Medium = control partial/undocumented).

# Compliance Review: [change title]
**Frameworks:** [PCI-DSS v4.0.1 / MAS TRM 2021] · **Date:** [YYYY-MM-DD]
**Scope:** [what was reviewed: files, design doc, pipeline]
> Engineering triage only — not a substitute for QSA assessment or the compliance function.

## Data & Boundary Analysis
- Data elements touched: [e.g. PAN (masked), customer NRIC, none]
- Environments/boundaries: [e.g. CDE-adjacent service, public API]

## Findings
| # | Control | Status | Severity | Finding | Remediation |
|---|---------|--------|----------|---------|-------------|
| 1 | [PCI 3.5.1] | Gap | Critical | [specific issue in this change] | [specific fix] |

## Ruled Out (not applicable)
- [Control area] — [one-line reason]

## Evidence Needed
- [Control]: [what artifact would demonstrate compliance]

Step 5: Offer story conversion

Offer to turn findings into backlog items with the control ID in each story for traceability.

Examples

Example 1: Logging review

User: "Is this PCI-DSS compliant: we log the full request body of card authorization calls for debugging?"

Skill: Loads pci-dss.md → Critical findings against 3.3.1 (CVV must never be stored post-authorization — logs are storage), 3.4.1 (PAN display masking), 3.5.1 (PAN unreadable at rest); remediation: remove the log line or apply a field-allowlist redaction filter; flags downstream log-pipeline scoping (10.3.x); QSA disclaimer included.

Example 2: Cloud migration

User: "Our Singapore bank is moving the customer notification service to a cloud region in another country. MAS TRM implications?"

Skill: Loads mas-trm.md → verifies the official cloud/third-party and data-security references (not §11.5, which concerns IoT) before mapping due diligence, cross-border data and exit risks, flags the MAS Outsourcing Guidelines as a related instrument, asks what customer data the service touches before rating severity.

Common FSI Engineering Triggers

Changes that almost always have compliance impact — check proactively when they appear in a diff:

• Logging statements near payment or authentication flows (CVV must not be stored after authorization; avoid full PAN logs and evaluate any storage against the applicable controls; MAS TRM requires security event logging — both directions matter)
• New data stores or caches receiving customer or card data (encryption at rest, retention, residency)
• Authentication/session changes (MFA requirements, session timeout, credential storage)
• New third-party SDKs or API integrations (outsourcing/vendor controls, data flows leaving the boundary)
• Infrastructure changes touching network segmentation, security groups, or public exposure
• CI/CD changes that alter who/what can deploy to production (change management, segregation of duties)

Guardrails

• Cite control IDs precisely (e.g. "PCI-DSS 8.3.6", "MAS TRM 9.1.1") so findings are traceable in audit tooling; verify each ID in the official version; the bundled MAS topic map is not paragraph-level authority.
• Severity discipline: don't inflate. A missing comment is not a Critical; unencrypted PAN at rest is.
• When the reviewed artifact supports a control, state that limited evidence result per control — "no findings" plus the checked-control list is a useful audit artifact.
• Never output real card numbers, even as examples; use the standard test PANs (e.g. 4111 1111 1111 1111) when illustrating.
• Read-only: this skill reviews and reports; it never modifies code, infrastructure, or configuration.

Limitations

• Covers only the bundled PCI-DSS v4.0.1 and MAS TRM engineering summaries; other frameworks or local policy overlays need separate review.
• Provides engineering triage, not legal advice, QSA assessment, or formal compliance sign-off.
• Requires concrete evidence such as diffs, designs, IaC, logs, or control artifacts; incomplete evidence should be marked Needs evidence.
• The bundled references are concise control maps, not substitutes for reading the official standards.

Credits

Adapted from [timwukp/agent-skills-best-practice](https://github.com/timwukp/agent-skills-best-practice) (MIT), where the skill ships with evals and a documented 4-layer test methodology (see the repo's TESTING.md).

Evidence and framework boundaries

A code diff cannot certify an organization, operating control or compliance program. Bind every finding to framework version, exact official paragraph, applicability, reviewed artifact and missing operational evidence. Use Needs evidence when a topic map is unverified; do not manufacture control IDs from the local table. Check MAS sector-specific Notices separately from nonbinding guidelines, including notification clocks and cross-border outsourcing requirements. Severity depends on demonstrated data exposure and control impact, not merely whether production data exists. Preserve any upstream credit as provenance only; upstream eval/test descriptions are not evidence that this imported skill was tested here. Keep cardholder data out of reports, including test PANs unless the demonstration specifically needs a clearly labeled approved sandbox value.