Update to Go: Fintech

{
  "description": "Use for Go payment compliance, sanctions, tokenization, audit, and PCI. Do not use for generic exploits or legal advice.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 270
    },
    {
      "relative_path": "evals.json",
      "size_in_bytes": 7529
    },
    {
      "relative_path": "references/control-boundaries.md",
      "size_in_bytes": 970
    },
    {
      "relative_path": "references/sanctions-screening-controls.md",
      "size_in_bytes": 3994
    },
    {
      "relative_path": "references/webhook-authenticity.md",
      "size_in_bytes": 3856
    },
    {
      "relative_path": "skill.json",
      "size_in_bytes": 3591
    }
  ],
  "name": "go-fintech-security-compliance",
  "skill_md_contents": "---\nname: go-fintech-security-compliance\ndescription: \"Use for Go payment compliance, sanctions, tokenization, audit, and PCI. Do not use for generic exploits or legal advice.\"\nlicense: Apache-2.0\ncompatibility: \"Go 1.24 or newer; standards and regulatory obligations require current qualified interpretation for the actual system.\"\n---\n\n# Go fintech security and compliance\n\nMinimize the systems and people that can store, process, transmit, or affect sensitive payment data. Compliance evidence must follow actual controls, not documentation theater.\n\n## Scope the data\n\nClassify account data, sensitive authentication data, PII, secrets, reusable payment/network tokens, detokenization handles, low-value opaque correlation IDs, derived identifiers, and audit records. Prefer hosted collection or tokenization that prevents raw data from entering the service. Map every store, log, queue, trace, backup, analytics stream, and support tool the data can reach.\n\nDo not retain applicable sensitive authentication data after authorization, even when encrypted. This includes card verification codes, PIN/PIN blocks, and full track data. Confirm the exact classification and disposition against the current PCI DSS and qualified assessor guidance for the deployed flow; code inspection cannot establish compliance.\n\nTokenization narrows scope only when raw collection, detokenization authority, routing, failure queues, telemetry, support access, analytics, backups, and model/tool inputs remain separated in the real data flow. Classify reusable tokens and detokenization handles as authority-bearing values. Prove deletion and retention outcomes across derived stores rather than deleting only the primary row.\n\n## Enforce authority\n\nAuthenticate users and services at an assurance level matching risk. Authorize by subject, tenant, action, resource, amount, and workflow state. Separate maker/checker or privileged approval where required. Rotate and revoke credentials; isolate cryptographic keys and record key version without logging secret material.\n\n## Preserve auditability\n\nRecord actor, authority, operation, target, before/after state reference, reason, time, correlation, and approval in tamper-evident durable storage. Keep logs and traces free of PAN, authentication data, reusable credentials or payment tokens, detokenization handles, secrets, and unnecessary PII. Classify token-like values before logging; an approved low-value correlation ID is not interchangeable with a reusable credential. Restrict access and test evidence retrieval.\n\n## Engineer change controls\n\nThreat-model sensitive changes, review generated artifacts and dependencies, pin CI inputs, separate duties for releases, prove rollback/migration behavior, and keep retention/deletion schedules enforceable. A checklist does not certify PCI DSS or any regulation; involve qualified security, compliance, and legal owners.\n\nRead [references/control-boundaries.md](references/control-boundaries.md) for tokenization, scope, retention, and audit failure cases.\n\nFor sanctions screening, holds, adjudication, list changes, and provider failure, read [references/sanctions-screening-controls.md](references/sanctions-screening-controls.md). Exact duties and dispositions come from the current risk-based compliance program and qualified legal/compliance owners, not from a match score or this skill.\n\nFor payment-provider callbacks, read [references/webhook-authenticity.md](references/webhook-authenticity.md). Verify the provider's exact signed representation and endpoint/account/environment key before trusting the payload, then separately enforce durable deduplication, ordering, authorization, and financial state invariants.\n\n## Output contract\n\nState data classification, trust boundary, authority decision, control owner, evidence, and residual compliance uncertainty. Never claim certification from code review.\n"
}