AgentSkillsCN

regulatory-compliance

根据适用的司法管辖区与框架,为MD-DDL实体应用监管与合规元数据。在建模具有监管要求的领域时,或当用户提及合规性、监管规定,或具体监管机构(如APRA、RBNZ、GDPR、巴塞尔等)时使用此功能。

SKILL.md
--- frontmatter
name: regulatory-compliance
description: Apply regulatory and compliance metadata to MD-DDL entities based on applicable jurisdictions and frameworks. Use when modeling domains with regulatory requirements or when user mentions compliance, regulations, or specific regulatory bodies (APRA, RBNZ, GDPR, Basel, etc.).

Regulatory Compliance

Identify Applicable Regulators

Ask user: "What regulatory jurisdictions and compliance frameworks apply to this data?"

Common regulators by jurisdiction:

JurisdictionRegulatorsRegulator Files to Load
Australia/NZ BankingAPRA, RBNZ, Basel, FATFapra.md, rbnz.md, basel.md, fatf.md
EUGDPR, Basel, EBAgdpr.md, basel.md, eba.md
US BankingFederal Reserve, OCC, FDIC, Baselfederal-reserve.md, occ.md, fdic.md, basel.md
US GeneralCCPA, SOXccpa.md, sox.md
Global AML/CTFFATFfatf.md
Healthcare (US)HIPAAhipaa.md
Healthcare (Global)VariousDepends on jurisdiction

Load Only Relevant Regulators

Critical: Only load regulator guidance files that apply to the user's jurisdiction and industry.

Example:

code
User: "We're a New Zealand bank owned by an Australian parent, need APRA and RBNZ compliance"
AI: Loading regulators/apra.md, regulators/rbnz.md, regulators/basel.md, regulators/fatf.md...
AI: (Does NOT load gdpr.md, ccpa.md, hipaa.md, etc.)

If user mentions specific compliance frameworks:

code
User: "We need to comply with GDPR for EU customers and APRA for Australian operations"
AI: Loading regulators/gdpr.md and regulators/apra.md...

Apply Regulatory Metadata

Once relevant regulator(s) loaded:

  1. User defines entity: "We need to model Customer"
  2. Consult loaded regulator guidance for metadata requirements
  3. Apply appropriate governance metadata to entity
  4. Include regulatory scope in domain and entity metadata

Example with APRA loaded:

code
User: "Model Customer entity"
AI: Checks regulators/apra.md → identifies PII requirements, CPS 234 scope
AI: Applies metadata:
  governance:
    classification: "Highly Confidential"
    pii: true
    regulatory_scope:
      - APRA CPS 234
      - APRA APS 222

Common Regulatory Metadata Properties

PropertyDescriptionExample Values
classificationData sensitivity level"Public", "Internal", "Confidential", "Highly Confidential"
piiContains personally identifiable informationtrue, false
regulatory_scopeWhich regulations applyList of regulations
retentionHow long data must be kept"7 years", "10 years post closure"
data_residencyWhere data must be stored["Australia", "New Zealand"]
cross_border_transferData crosses jurisdictional borderstrue, false
audit_all_accessAll access must be loggedtrue, false
breach_notification_requiredMust notify regulator of breachestrue, false

Domain-Level Regulatory Metadata

Set default regulatory posture at domain level:

yaml
# In domain.md Metadata section
governance:
  classification: "Highly Confidential"  # Default for all entities
  pii: true
  regulatory_scope:
    - APRA CPS 234
    - RBNZ BS13
    - Basel III
    - FATF AML/CTF
  default_retention: "7 years post relationship end"
  data_residency: ["Australia", "New Zealand"]

Entities can override domain defaults when needed.

Entity-Level Regulatory Metadata

Apply specific requirements to individual entities:

yaml
# In entities/customer.md
governance:
  classification: "Highly Confidential"
  pii: true
  pii_fields:
    - Date of Birth
    - Tax Identification Number
    - Email Address
  regulatory_scope:
    - APRA CPS 234 (Information Security)
    - APRA APS 222 (Associations with Related Entities)
    - RBNZ BS13 (Governance)
  retention: "10 years post relationship end"
  retention_basis: "APRA record keeping requirements"
  audit_all_access: true
  breach_notification_required: true
  notification_timeframe: "72 hours"

Dual/Multiple Jurisdiction Scenarios

For organizations operating in multiple jurisdictions:

yaml
governance:
  regulatory_scope:
    - APRA CPS 234 (parent company - Australia)
    - RBNZ BS13 (local subsidiary - New Zealand)
    - Basel III (international capital standards)
  
  data_residency: ["Australia", "New Zealand"]
  
  dual_reporting: true
  reporting_frameworks:
    - APRA ARF 320 (quarterly)
    - RBNZ Financial Statements (quarterly)

Compliance Framework Mapping

Map entities to specific reporting frameworks:

yaml
governance:
  apra_reporting:
    arf_320_0: true   # Statement of Financial Position
    arf_320_1a: true  # Balance Sheet
  
  rbnz_reporting:
    financial_statements: true
    capital_adequacy: true
  
  basel_reporting:
    credit_risk_exposure: true
    operational_risk: true

AML/CTF Specific Metadata

For financial crime monitoring (FATF requirements):

yaml
governance:
  aml_relevant: true
  ctf_relevant: true
  fatf_scope: true
  
  monitoring_required: true
  screening_required: true
  screening_lists:
    - UN Sanctions
    - OFAC
    - Local Sanctions
  
  enhanced_due_diligence: false  # Default, override for high-risk
  pep_screening: true

Loading Additional Regulators Mid-Modeling

If during modeling you discover need for another regulator:

Ask user: "I notice you're modeling {concept} which may be subject to {additional regulator}. Should we include that compliance framework?"

Example:

code
User modeling customer data (APRA loaded)
AI: "I notice you're collecting EU customer data. Should we also apply GDPR requirements?"
User: "Yes, we have EU operations"
AI: Loading regulators/gdpr.md...
AI: Applying GDPR-specific metadata (right to erasure, consent tracking, etc.)

Only load when:

  • User explicitly requests
  • Clear regulatory trigger identified (e.g., cross-border data, specific data types)
  • User confirms the additional regulator applies

Validation

Before applying regulatory metadata:

  1. Confirm loaded regulator guidance applies to this entity
  2. Check entity type against regulator requirements (e.g., APRA CPS 234 applies to "material information assets")
  3. Verify retention periods align with business lifecycle
  4. Ensure data residency requirements are feasible

When No Regulatory Requirements

If entity has no specific regulatory requirements:

  • Omit detailed regulatory metadata
  • May still include basic classification and retention
  • Document in detail file: "No specific regulatory requirements identified"

Related Skills