Fsi compliance checker
Skill timwukp/agent-skills-best-practice/skills/skills/fsi-compliance-checker
35 portable agent skills (Agent Skills spec) for Kiro & Claude Code: Scrum DevSecOps roles, PCI-DSS/MAS TRM compliance, AWS Well-Architected reviews — each with evals and a 4-layer tested methodology
npx -y skills add timwukp/agent-skills-best-practice --skill fsi-compliance-checkerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 7 stars7 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Maps code, architecture, and infrastructure changes to specific control IDs in financial services compliance frameworks - PCI-DSS v4.0 for payment card data and MAS TRM for Singapore-regulated institutions - producing an audit-traceable findings report with per-control remediation. Use this instead of a general security review whenever a compliance framework (PCI-DSS, MAS TRM), regulator, audit, or cardholder-data scope is mentioned, even if the request is phrased as a code review or a yes/no compliance question. Triggers on: "PCI-DSS check", "MAS TRM", "is this compliant", "compliance review", "audit this change for banking regulations", "does logging this violate PCI", "cardholder data handling review".
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.2 KB, as published. Nobody here has run it
FSI Compliance Checker
Map a concrete change (code diff, architecture design, IaC, pipeline config) to the specific controls it touches in financial services compliance frameworks, and report 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.
Framework Selection
Load only the reference file(s) the engagement needs:
| Situation | Load |
|---|---|
| Payment card data is stored, processed, or transmitted (PAN, CVV, track data) | references/pci-dss.md |
| Singapore-regulated financial institution (bank, insurer, capital markets, major payment institution) | references/mas-trm.md |
| Both apply (e.g. Singapore bank handling cards) | Both files |
| Other jurisdictions/frameworks (SOX, GDPR, HKMA, APRA) | State that they are out of scope of this skill's bundled references; 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?
Review Process
- 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.
- Select 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 applicable control against the change:
Compliant/Gap/Needs evidence(can't tell from the artifact — name the evidence required). - Write findings using the report format below. 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).
- Recommend story conversion: offer to turn findings into backlog items (via the security-story-writing skill if available) with the control ID in each story for traceability.
Report Format
# Compliance Review: [change title]
**Frameworks:** [PCI-DSS v4.0 / 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]
Common FSI Engineering Triggers
Changes that almost always have compliance impact — check these proactively when they appear in a diff:
- Logging statements near payment or authentication flows (PAN/CVV must never be logged; 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)
Guidelines
- Cite control IDs precisely (e.g. "PCI-DSS 8.3.6", "MAS TRM 9.1.1") so findings are traceable in audit tooling; the reference files carry the ID schemes.
- Severity discipline: don't inflate. A missing comment is not a Critical; unencrypted PAN at rest is.
- When the change is compliant, say so affirmatively 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.