@1aboveio/skills 0.20.2 → 0.20.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +14 -6
- package/package.json +1 -1
- package/runtime/skills/distribution/generated/recipes.json +220 -25
- package/runtime/skills/distribution/scripts/bundles.mjs +167 -48
- package/runtime/skills/engineering/engineering-runtime/scripts/workflow-coherence.mjs +4 -0
- package/runtime/skills/engineering/engineering-runtime/scripts/workflow-policy.mjs +1 -1
- package/skills/compliance/compliance-audit/LICENSE +3 -0
- package/skills/compliance/compliance-audit/SKILL.md +466 -0
- package/skills/compliance/compliance-audit/references/findings-schema.md +290 -0
- package/skills/compliance/compliance-audit/references/vars-checklist.md +1068 -0
- package/skills/compliance/compliance-audit/references/vars-findings-schema.md +395 -0
- package/skills/compliance/compliance-audit/scripts/reconcile_tracker.py +454 -0
- package/skills/compliance/compliance-audit/scripts/test_validate_tracker.py +90 -0
- package/skills/compliance/compliance-audit/scripts/validate_tracker.py +752 -0
- package/skills/compliance/doc-authenticity/LICENSE +3 -0
- package/skills/compliance/doc-authenticity/SKILL.md +158 -0
- package/skills/compliance/doc-authenticity/references/agreement.md +66 -0
- package/skills/compliance/doc-authenticity/references/bank-statement.md +150 -0
- package/skills/compliance/doc-authenticity/references/forensic-signals.md +157 -0
- package/skills/compliance/doc-authenticity/references/image-signals.md +114 -0
- package/skills/compliance/doc-authenticity/references/invoice.md +66 -0
- package/skills/compliance/doc-authenticity/references/issuer-profiles.md +86 -0
- package/skills/compliance/doc-authenticity/references/verdict-and-report.md +95 -0
- package/skills/compliance/doc-authenticity/references/verdict.schema.json +81 -0
- package/skills/compliance/doc-authenticity/scripts/image_forensics.py +294 -0
- package/skills/compliance/doc-authenticity/scripts/pdf_forensics.py +401 -0
- package/skills/compliance/doc-authenticity/scripts/validate_codes.py +224 -0
- package/skills/compliance/doc-authenticity/scripts/validate_verdict.py +308 -0
- package/skills/compliance/report-writing/LICENSE +3 -0
- package/skills/compliance/report-writing/SKILL.md +206 -0
- package/skills/compliance/report-writing/references/audit-report-template.md +121 -0
- package/skills/compliance/report-writing/references/external-assessment-template.md +167 -0
- package/skills/compliance/report-writing/references/management-report-template.md +145 -0
- package/skills/compliance/report-writing/references/vars-report-template.md +224 -0
- package/skills/document-utils/doc-to-md/LICENSE +3 -0
- package/skills/document-utils/doc-to-md/SKILL.md +77 -0
- package/skills/document-utils/doc-to-md/scripts/convert.py +157 -0
- package/skills/document-utils/reg-parser/LICENSE +3 -0
- package/skills/document-utils/reg-parser/SKILL.md +201 -0
- package/skills/document-utils/reg-parser/references/checklist-schema.md +223 -0
- package/skills/document-utils/reg-parser/references/checklists/hk-amlo-checklist.json +1306 -0
- package/skills/document-utils/reg-parser/references/checklists/hk-amlo-checklist.md +469 -0
- package/skills/document-utils/reg-parser/references/checklists/hk-fi-corporate-onboarding-cdd-checklist.json +634 -0
- package/skills/document-utils/reg-parser/references/checklists/hk-fi-corporate-onboarding-cdd-checklist.md +233 -0
- package/skills/document-utils/reg-parser/references/checklists/hk-mso-guideline-checklist.json +2194 -0
- package/skills/document-utils/reg-parser/references/checklists/hk-mso-guideline-checklist.md +771 -0
- package/skills/document-utils/reg-parser/references/checklists/kyc-aml-checklist.md +258 -0
- package/skills/document-utils/reg-parser/references/checklists/visa-vars-checklist.md +1058 -0
- package/skills/document-utils/reg-parser/references/mandates/hk-amlo-cap615.md +389 -0
- package/skills/document-utils/reg-parser/references/mandates/visa-vars.md +205 -0
- package/skills/document-utils/reg-parser/scripts/compare_checklist.py +228 -0
- package/skills/document-utils/reg-parser/scripts/dump_checklist.py +348 -0
- package/skills/document-utils/reg-parser/scripts/preprocess-mandate.sh +171 -0
- package/skills/document-utils/reg-parser/scripts/test_quarantine.sh +102 -0
- package/skills/document-utils/reg-parser/scripts/validate_checklist.py +532 -0
- package/skills/document-utils/reg-parser/scripts/validate_mandate.py +242 -0
- package/skills/engineering/engineering-runtime/coherence/workflow.json +16 -16
- package/skills/engineering/engineering-runtime/scripts/workflow-coherence.mjs +4 -0
- package/skills/engineering/engineering-runtime/scripts/workflow-policy.mjs +1 -1
- package/skills/payment/similar-domain/LICENSE +3 -0
- package/skills/payment/similar-domain/SKILL.md +178 -0
- package/skills/payment/similar-domain/references/entities.md +58 -0
- package/skills/payment/similar-domain/references/fingerprints.md +82 -0
- package/skills/payment/similar-domain/references/pivots.md +66 -0
- package/skills/payment/similar-domain/references/report-template.md +76 -0
- package/skills/payment/similar-domain/references/scoring.md +61 -0
- package/skills/payment/similar-domain/references/terminology.md +37 -0
- package/skills/payment/similar-domain/references/workflow.md +79 -0
- package/skills/payment/tld-detection/SKILL.md +76 -21
- package/skills/payment/tld-detection/references/clean.md +1 -1
- package/skills/payment/tld-detection/references/clustering.md +21 -6
- package/skills/payment/tld-detection/references/decision.md +7 -2
- package/skills/payment/tld-detection/references/fx-conversion.md +229 -0
- package/skills/payment/tld-detection/references/report-template.md +63 -27
- package/skills/payment/tld-detection/references/streams.md +90 -0
- package/skills/payment/tld-detection/references/terminology.md +15 -7
- package/skills/payment/tld-detection/references/workflow.md +1 -1
- package/skills/payment/tld-detection/scripts/detect_streams.py +542 -0
- package/skills/engineering/ensure-coverage/evals/evals.json +0 -125
- package/skills/engineering/rush-issues/evals/evals.json +0 -65
- package/skills/engineering/rush-release/evals/evals.json +0 -58
- package/skills/fullstack/shadcn/evals/evals.json +0 -90
- package/skills/payment/fraud-analysis/evals/evals.json +0 -40
- package/skills/payment/tld-detection/evals/evals.json +0 -107
- package/skills/payment/tld-detection/tests/test_detect_ladders.py +0 -132
|
@@ -0,0 +1,167 @@
|
|
|
1
|
+
# External Assessment Template
|
|
2
|
+
|
|
3
|
+
Use this structure for regulatory or external auditor submissions (audience: regulators,
|
|
4
|
+
certification bodies, external auditors).
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Cover Page
|
|
9
|
+
|
|
10
|
+
| Field | Value |
|
|
11
|
+
|---|---|
|
|
12
|
+
| Document Title | {Framework} Compliance Assessment Report |
|
|
13
|
+
| Prepared For | {Regulatory body / Certification body / Client name} |
|
|
14
|
+
| Prepared By | {Assessor organization, qualifications} |
|
|
15
|
+
| Assessment Period | {Start Date} – {End Date} |
|
|
16
|
+
| Report Date | {YYYY-MM-DD} |
|
|
17
|
+
| Document Version | {e.g., 1.0} |
|
|
18
|
+
| Classification | {Confidential} |
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## 1. Scope Statement
|
|
23
|
+
|
|
24
|
+
### 1.1 Purpose
|
|
25
|
+
|
|
26
|
+
{State the purpose of the assessment. Reference the specific regulation, standard, or
|
|
27
|
+
contractual obligation that mandates this assessment.}
|
|
28
|
+
|
|
29
|
+
Example: "This assessment evaluates [Organization]'s compliance with [Regulation/Standard]
|
|
30
|
+
as required under [Article/Section]. The assessment covers [systems/processes/data]
|
|
31
|
+
within the defined scope boundary."
|
|
32
|
+
|
|
33
|
+
### 1.2 Scope Boundary
|
|
34
|
+
|
|
35
|
+
{Define what is in scope and out of scope. Be explicit about:}
|
|
36
|
+
- Systems and applications assessed
|
|
37
|
+
- Business processes covered
|
|
38
|
+
- Data types and classifications included
|
|
39
|
+
- Geographic locations
|
|
40
|
+
- Third-party dependencies included/excluded
|
|
41
|
+
|
|
42
|
+
### 1.3 Assessment Period
|
|
43
|
+
|
|
44
|
+
{The time window covered by this assessment.}
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## 2. Assessment Methodology
|
|
49
|
+
|
|
50
|
+
### 2.1 Approach
|
|
51
|
+
|
|
52
|
+
{Describe the methodology: control testing, evidence review, interviews, technical
|
|
53
|
+
validation. Reference any recognized assessment framework used (e.g., ISAE 3402,
|
|
54
|
+
AICPA Trust Services Criteria).}
|
|
55
|
+
|
|
56
|
+
### 2.2 Sampling
|
|
57
|
+
|
|
58
|
+
{Describe sampling methodology and rationale. State sample sizes and selection criteria.}
|
|
59
|
+
|
|
60
|
+
### 2.3 Limitations
|
|
61
|
+
|
|
62
|
+
{State any limitations, caveats, or constraints that affected the assessment.}
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## 3. Compliance Status by Requirement
|
|
67
|
+
|
|
68
|
+
Organize by regulation article or standard control domain. Each requirement gets a
|
|
69
|
+
status determination with supporting rationale.
|
|
70
|
+
|
|
71
|
+
### 3.1 {Requirement Domain / Article}
|
|
72
|
+
|
|
73
|
+
#### {Article/Section Number}: {Requirement Title}
|
|
74
|
+
|
|
75
|
+
| Field | Detail |
|
|
76
|
+
|---|---|
|
|
77
|
+
| **Requirement** | {Full text or summary of the regulatory requirement} |
|
|
78
|
+
| **Regulation Reference** | {e.g., Article 32(1)(a), Regulation (EU) 2016/679} |
|
|
79
|
+
| **Compliance Status** | {Compliant / Partially Compliant / Non-Compliant / Not Applicable} |
|
|
80
|
+
| **Severity of Gap** | {Critical / Major / Minor / N/A} |
|
|
81
|
+
|
|
82
|
+
**Assessment Rationale:**
|
|
83
|
+
{Explain the basis for the status determination. Reference specific controls observed,
|
|
84
|
+
evidence reviewed, and tests performed.}
|
|
85
|
+
|
|
86
|
+
**Identified Gaps:**
|
|
87
|
+
{If not fully compliant, describe each gap precisely. Reference the specific
|
|
88
|
+
sub-requirement that is not met.}
|
|
89
|
+
|
|
90
|
+
**Recommended Remediation:**
|
|
91
|
+
{Steps to achieve compliance. Reference industry best practices or regulatory guidance.}
|
|
92
|
+
|
|
93
|
+
{Repeat for each requirement/article.}
|
|
94
|
+
|
|
95
|
+
---
|
|
96
|
+
|
|
97
|
+
## 4. Gap Analysis Matrix
|
|
98
|
+
|
|
99
|
+
Summary view mapping each requirement to its compliance status.
|
|
100
|
+
|
|
101
|
+
| Requirement | Reference | Status | Severity | Remediation Target |
|
|
102
|
+
|---|---|---|---|---|
|
|
103
|
+
| {Requirement title} | {Article/Section} | {Status} | {Severity} | {Target date} |
|
|
104
|
+
| {Requirement title} | {Article/Section} | {Status} | {Severity} | {Target date} |
|
|
105
|
+
|
|
106
|
+
### Summary Statistics
|
|
107
|
+
|
|
108
|
+
| Status | Count | Percentage |
|
|
109
|
+
|---|---|---|
|
|
110
|
+
| Compliant | {n} | {%} |
|
|
111
|
+
| Partially Compliant | {n} | {%} |
|
|
112
|
+
| Non-Compliant | {n} | {%} |
|
|
113
|
+
| Not Applicable | {n} | {%} |
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## 5. Remediation Roadmap
|
|
118
|
+
|
|
119
|
+
| Priority | Requirement | Gap Description | Recommended Action | Target Date | Effort Estimate |
|
|
120
|
+
|---|---|---|---|---|---|
|
|
121
|
+
| P1 | {Ref} | {Gap} | {Action} | {Date} | {Estimate} |
|
|
122
|
+
| P2 | {Ref} | {Gap} | {Action} | {Date} | {Estimate} |
|
|
123
|
+
|
|
124
|
+
---
|
|
125
|
+
|
|
126
|
+
## 6. Attestation Statement
|
|
127
|
+
|
|
128
|
+
> Based on the assessment conducted during the period {Start Date} to {End Date},
|
|
129
|
+
> applying the methodology described in Section 2, and having reviewed the evidence
|
|
130
|
+
> documented herein, {Assessor Organization} [attests/concludes] the following:
|
|
131
|
+
>
|
|
132
|
+
> {Organization} has demonstrated {[full/substantial/partial]} compliance with
|
|
133
|
+
> {Regulation/Standard} within the defined scope.
|
|
134
|
+
>
|
|
135
|
+
> {Number} requirements were assessed. Of these, {n} were found fully compliant,
|
|
136
|
+
> {n} partially compliant, and {n} non-compliant.
|
|
137
|
+
>
|
|
138
|
+
> The findings documented in this report represent the compliance posture as of
|
|
139
|
+
> {Report Date}. This attestation does not guarantee future compliance.
|
|
140
|
+
>
|
|
141
|
+
> **Assessor:** {Name, Title, Qualification}
|
|
142
|
+
> **Date:** {YYYY-MM-DD}
|
|
143
|
+
> **Signature:** ____________________
|
|
144
|
+
|
|
145
|
+
---
|
|
146
|
+
|
|
147
|
+
## Appendix A: Evidence Index
|
|
148
|
+
|
|
149
|
+
| Evidence ID | Description | Requirement Ref | Type | Date |
|
|
150
|
+
|---|---|---|---|---|
|
|
151
|
+
| E-001 | {Description} | {Article/Section} | {Type} | {Date} |
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
## Appendix B: Assessor Qualifications
|
|
156
|
+
|
|
157
|
+
| Assessor | Qualifications | Role in Assessment |
|
|
158
|
+
|---|---|---|
|
|
159
|
+
| {Name} | {e.g., CISA, CISSP, ISO 27001 Lead Auditor} | {Lead Assessor / Technical Reviewer} |
|
|
160
|
+
|
|
161
|
+
---
|
|
162
|
+
|
|
163
|
+
## Appendix C: Document Control
|
|
164
|
+
|
|
165
|
+
| Version | Date | Author | Changes |
|
|
166
|
+
|---|---|---|---|
|
|
167
|
+
| 1.0 | {Date} | {Author} | Initial release |
|
|
@@ -0,0 +1,145 @@
|
|
|
1
|
+
# Management Report Template
|
|
2
|
+
|
|
3
|
+
Use this structure for leadership and board-level reporting (audience: C-suite, board,
|
|
4
|
+
risk committee).
|
|
5
|
+
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
## Report Metadata
|
|
9
|
+
|
|
10
|
+
| Field | Value |
|
|
11
|
+
|---|---|
|
|
12
|
+
| Report Title | Compliance Posture — {Framework} Assessment |
|
|
13
|
+
| Report Date | {YYYY-MM-DD} |
|
|
14
|
+
| Assessment Period | {Start Date} – {End Date} |
|
|
15
|
+
| Prepared By | {Compliance Team / Assessor} |
|
|
16
|
+
| Classification | {Confidential — Board Distribution} |
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## 1. Executive Summary
|
|
21
|
+
|
|
22
|
+
{One page maximum. This section stands alone — a reader should understand the
|
|
23
|
+
organization's compliance posture without reading further.}
|
|
24
|
+
|
|
25
|
+
**Overall Compliance Posture:** {Strong / Adequate / Needs Improvement / Critical}
|
|
26
|
+
|
|
27
|
+
**Headline Numbers:**
|
|
28
|
+
- **{N}** controls assessed across **{N}** categories
|
|
29
|
+
- **{N}%** fully compliant
|
|
30
|
+
- **{N}** critical gaps requiring immediate action
|
|
31
|
+
- **{N}** major gaps requiring near-term remediation
|
|
32
|
+
|
|
33
|
+
**Key Message:**
|
|
34
|
+
{2–3 sentences summarizing the most important takeaway. Focus on business risk, not
|
|
35
|
+
technical details. Example: "Two critical gaps in access management expose the
|
|
36
|
+
organization to regulatory penalty risk estimated at $X–$Y. Remediation requires
|
|
37
|
+
approximately N engineer-weeks and should begin immediately."}
|
|
38
|
+
|
|
39
|
+
**Immediate Actions Required:**
|
|
40
|
+
1. {Action 1 — one line, business language}
|
|
41
|
+
2. {Action 2}
|
|
42
|
+
3. {Action 3}
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## 2. Risk Heatmap
|
|
47
|
+
|
|
48
|
+
Findings by severity and category. Use this to identify concentration areas.
|
|
49
|
+
|
|
50
|
+
| Category | 🔴 Critical | 🟠 Major | 🟡 Minor | 🔵 Observation | Total |
|
|
51
|
+
|---|---|---|---|---|---|
|
|
52
|
+
| Access Control | {n} | {n} | {n} | {n} | {n} |
|
|
53
|
+
| Data Protection | {n} | {n} | {n} | {n} | {n} |
|
|
54
|
+
| Incident Response | {n} | {n} | {n} | {n} | {n} |
|
|
55
|
+
| Change Management | {n} | {n} | {n} | {n} | {n} |
|
|
56
|
+
| Vendor Management | {n} | {n} | {n} | {n} | {n} |
|
|
57
|
+
| {Other categories} | | | | | |
|
|
58
|
+
| **Total** | **{n}** | **{n}** | **{n}** | **{n}** | **{n}** |
|
|
59
|
+
|
|
60
|
+
**Concentration Risk:**
|
|
61
|
+
{Identify categories with multiple critical/major findings. Example: "Access Control
|
|
62
|
+
accounts for 60% of critical findings, indicating a systemic control weakness."}
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
## 3. Business Impact Analysis
|
|
67
|
+
|
|
68
|
+
For each critical and major finding, translate technical risk into business terms.
|
|
69
|
+
|
|
70
|
+
### 3.1 {Finding Category / Theme}
|
|
71
|
+
|
|
72
|
+
**What's at risk:**
|
|
73
|
+
{Business impact in plain language. Examples: customer data exposure, regulatory fine,
|
|
74
|
+
operational disruption, reputational damage, contract breach.}
|
|
75
|
+
|
|
76
|
+
**Quantified impact (where estimable):**
|
|
77
|
+
- Regulatory penalty exposure: {$X – $Y}
|
|
78
|
+
- Potential data records affected: {N}
|
|
79
|
+
- Operational downtime risk: {hours/days}
|
|
80
|
+
- Contract/SLA breach exposure: {description}
|
|
81
|
+
|
|
82
|
+
**Likelihood:** {High / Medium / Low}
|
|
83
|
+
|
|
84
|
+
{Repeat for each significant impact area.}
|
|
85
|
+
|
|
86
|
+
---
|
|
87
|
+
|
|
88
|
+
## 4. Recommended Actions
|
|
89
|
+
|
|
90
|
+
Prioritized actions with effort and cost estimates. Designed for resource allocation decisions.
|
|
91
|
+
|
|
92
|
+
| # | Action | Addresses | Priority | Effort | Cost Estimate | Suggested Owner | Target Date |
|
|
93
|
+
|---|---|---|---|---|---|---|---|
|
|
94
|
+
| 1 | {Action description} | {Finding refs} | 🔴 Immediate | {e.g., 3 weeks} | {$X} | {Role/Dept} | {Date} |
|
|
95
|
+
| 2 | {Action description} | {Finding refs} | 🟠 Near-term | {e.g., 6 weeks} | {$X} | {Role/Dept} | {Date} |
|
|
96
|
+
| 3 | {Action description} | {Finding refs} | 🟡 Planned | {e.g., Q3} | {$X} | {Role/Dept} | {Date} |
|
|
97
|
+
|
|
98
|
+
**Total estimated remediation investment:** {$X over N months}
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## 5. Progress Since Last Assessment
|
|
103
|
+
|
|
104
|
+
{Include only when prior assessment data is available. If this is a baseline assessment,
|
|
105
|
+
state: "This is the initial baseline assessment. Progress tracking begins with the
|
|
106
|
+
next assessment cycle."}
|
|
107
|
+
|
|
108
|
+
### Trend Summary
|
|
109
|
+
|
|
110
|
+
| Metric | Prior ({Date}) | Current | Change |
|
|
111
|
+
|---|---|---|---|
|
|
112
|
+
| Overall compliance rate | {%} | {%} | {↑/↓ Δ%} |
|
|
113
|
+
| Critical findings | {n} | {n} | {↑/↓ Δn} |
|
|
114
|
+
| Major findings | {n} | {n} | {↑/↓ Δn} |
|
|
115
|
+
| Open remediation items | {n} | {n} | {↑/↓ Δn} |
|
|
116
|
+
|
|
117
|
+
### Remediation Closure Rate
|
|
118
|
+
|
|
119
|
+
- Items from prior assessment: {N}
|
|
120
|
+
- Closed / remediated: {N} ({%})
|
|
121
|
+
- Still open: {N}
|
|
122
|
+
- New findings this cycle: {N}
|
|
123
|
+
|
|
124
|
+
### Notable Improvements
|
|
125
|
+
|
|
126
|
+
{Bullet list of specific improvements since the last assessment.}
|
|
127
|
+
|
|
128
|
+
### Persistent Gaps
|
|
129
|
+
|
|
130
|
+
{Findings that remain open from the prior assessment, with explanation of delays.}
|
|
131
|
+
|
|
132
|
+
---
|
|
133
|
+
|
|
134
|
+
## 6. Appendix
|
|
135
|
+
|
|
136
|
+
### Methodology Note
|
|
137
|
+
|
|
138
|
+
{Brief description of assessment approach, framework used, and scope. Keep to one
|
|
139
|
+
paragraph — detailed methodology is in the full audit report.}
|
|
140
|
+
|
|
141
|
+
### Detailed Data Reference
|
|
142
|
+
|
|
143
|
+
{Reference to the full Audit Report for technical details: "For complete finding
|
|
144
|
+
details, evidence, and technical remediation steps, refer to the Audit Report
|
|
145
|
+
dated {Date}."}
|
|
@@ -0,0 +1,224 @@
|
|
|
1
|
+
# VARS Review Report Template
|
|
2
|
+
|
|
3
|
+
Authoritative template for **Visa Acceptance Risk Standards (VARS)** review reports
|
|
4
|
+
distributed by Visa to acquirers. Mirrors Visa's official 2025 *Visa Acceptance Risk
|
|
5
|
+
Standards Report Template* (Confidential, Final).
|
|
6
|
+
|
|
7
|
+
Use this template **verbatim** for VARS engagements — section numbering, headings,
|
|
8
|
+
ordering, and the nine VARS sub-domains are fixed by Visa. Do not rename, reorder, or
|
|
9
|
+
omit sections without explicit instruction.
|
|
10
|
+
|
|
11
|
+
## Source of truth: the full assessment tracker
|
|
12
|
+
|
|
13
|
+
A VARS Review Report is **always** a roll-up of a complete control-by-control
|
|
14
|
+
assessment against the VARS checklist. The expected input is the `tracker.md` produced
|
|
15
|
+
by the `compliance-audit` skill (or a directly-equivalent worksheet) covering **all
|
|
16
|
+
nine sub-domains**. The report itself is the executive layer; per-control evidence,
|
|
17
|
+
testing notes, and remediation owners live in the companion *VARS Control Testing and
|
|
18
|
+
Remediation Tracking* spreadsheet, which is the same tracker in Visa's Excel format.
|
|
19
|
+
|
|
20
|
+
Before drafting:
|
|
21
|
+
1. Confirm the tracker exists and covers all nine sub-domains. If any are missing or
|
|
22
|
+
marked "Not Assessed", stop and raise it — do not paper over gaps in the report.
|
|
23
|
+
2. Confirm every control row has a status and a severity. Section 4 priorities and
|
|
24
|
+
Section 3.d summary statements both depend on these.
|
|
25
|
+
3. Note the tracker's filename and version — it will be referenced from Section 5 and
|
|
26
|
+
should accompany the report when distributed.
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## Cover page
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
Visa Acceptance Risk Standards (VARS)
|
|
34
|
+
Review Report
|
|
35
|
+
|
|
36
|
+
Author: {{assessor name}}
|
|
37
|
+
Date: {{YYYY-MM-DD}}
|
|
38
|
+
Document Status: Final
|
|
39
|
+
Type of Review: Visa Acceptance Risk Standards (VARS)
|
|
40
|
+
Version: {{n}}
|
|
41
|
+
Document Classification: Confidential
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## Table of Contents
|
|
45
|
+
|
|
46
|
+
Auto-generate from the section headings below.
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## Section 1: Document History
|
|
51
|
+
|
|
52
|
+
| Version | Date | Updated By | Description |
|
|
53
|
+
|---------|---------|------------|-------------------|
|
|
54
|
+
| 1.0 | | | Document Creation |
|
|
55
|
+
| 2.0 | MM/YEAR | | Updated Report |
|
|
56
|
+
| 3.0 | MM/YEAR | | Final Report |
|
|
57
|
+
|
|
58
|
+
## Section 2: Document Distribution List — Acquirer Bank and Visa
|
|
59
|
+
|
|
60
|
+
| Position | Name | Date |
|
|
61
|
+
|----------|------|------|
|
|
62
|
+
| | | |
|
|
63
|
+
|
|
64
|
+
(Repeat rows for each distribution recipient.)
|
|
65
|
+
|
|
66
|
+
---
|
|
67
|
+
|
|
68
|
+
## Section 3: Executive Summary
|
|
69
|
+
|
|
70
|
+
### a. Purpose
|
|
71
|
+
|
|
72
|
+
> The purpose of this VARS Control Assessment is to perform an evaluation of the risk
|
|
73
|
+
> profile and controls used by the Acquirer to manage its acquiring program and
|
|
74
|
+
> maintain compliance with the Visa Acceptance Risk Standards (VARS). This review is
|
|
75
|
+
> based on the VARS Guide, Visa Core Rules and Visa Product and Service Rules
|
|
76
|
+
> requirements.
|
|
77
|
+
|
|
78
|
+
(Use the paragraph above verbatim. Do not paraphrase.)
|
|
79
|
+
|
|
80
|
+
### b. Background
|
|
81
|
+
|
|
82
|
+
Describe the Acquirer: legal entity, license/registration, acquiring footprint,
|
|
83
|
+
portfolio scale, and the policies, procedures, and controls in place for VARS
|
|
84
|
+
compliance. Close with the assessment objective:
|
|
85
|
+
|
|
86
|
+
> The objective of this Visa Control Assessment is to evaluate the effectiveness and
|
|
87
|
+
> adequacy of the Acquirer's controls for managing its portfolio, Third Parties,
|
|
88
|
+
> identifying any gaps or weaknesses that may pose a risk to the Visa payment system,
|
|
89
|
+
> and providing recommendations for improvement.
|
|
90
|
+
|
|
91
|
+
### c. VARS Control Assessment
|
|
92
|
+
|
|
93
|
+
State the onsite review interview date. Confirm adherence to VARS Guide, Visa Core
|
|
94
|
+
Rules, and Visa Product and Service Rules. List scope:
|
|
95
|
+
|
|
96
|
+
- Self-Assessment Questionnaire (SAQ) and evidence review, conducted by Visa.
|
|
97
|
+
- Control Assessment interview with key Acquirer staff; further evidence and samples
|
|
98
|
+
shared during the assessment. Focus VARS sub-domains:
|
|
99
|
+
- Chargebacks/Disputes
|
|
100
|
+
- Data Integrity/Quality
|
|
101
|
+
- Data Security
|
|
102
|
+
- Monitoring
|
|
103
|
+
- Network and Scheme Compliance
|
|
104
|
+
- Onboarding
|
|
105
|
+
- Regulatory Risk
|
|
106
|
+
- Risk Appetite and Policy Framework
|
|
107
|
+
- Written Agreement
|
|
108
|
+
- Visa shared observations during the session.
|
|
109
|
+
- Visa prepares and distributes the VARS Review Report.
|
|
110
|
+
|
|
111
|
+
Close with the reliance statement:
|
|
112
|
+
|
|
113
|
+
> Visa relies on the information, evidence and comments shared by the Acquirer, and
|
|
114
|
+
> to the best of our knowledge these findings are accurate.
|
|
115
|
+
|
|
116
|
+
### d. Summary of Findings
|
|
117
|
+
|
|
118
|
+
**Audience: executive.** Open with a one- or two-sentence overall-posture headline —
|
|
119
|
+
how many areas are Satisfactory, where the single material gap (if any) sits, and
|
|
120
|
+
whether any issue poses critical exposure to the Visa payment system. Then give **one
|
|
121
|
+
bullet per sub-domain with a 2–3 sentence, business-oriented summary**: the posture and
|
|
122
|
+
its risk/business implication, in plain language. Keep it **non-operational** — no
|
|
123
|
+
control IDs, document names, or clause-level detail (that belongs in Section 4 / the
|
|
124
|
+
tracker). **Always list all nine sub-domains in this order** (add a **Third Party Agent**
|
|
125
|
+
bullet when the ATPA archetype is in scope — see Section 4):
|
|
126
|
+
|
|
127
|
+
- **Risk Appetite and Policy Framework:** {{2–3 sentence business posture}}
|
|
128
|
+
- **Written Agreement:** {{…}}
|
|
129
|
+
- **Onboarding:** {{…}}
|
|
130
|
+
- **Monitoring:** {{…}}
|
|
131
|
+
- **Chargebacks/Disputes:** {{…}}
|
|
132
|
+
- **Data Integrity/Quality:** {{…}}
|
|
133
|
+
- **Data Security:** {{…}}
|
|
134
|
+
- **Network and Scheme Compliance:** {{…}}
|
|
135
|
+
- **Regulatory Risk:** {{…}}
|
|
136
|
+
|
|
137
|
+
Example — `**Onboarding — Satisfactory:** Prospective merchants are risk-assessed,
|
|
138
|
+
identity-verified, sanctions-screened and fraud-checked before they can transact. This
|
|
139
|
+
keeps higher-risk and illegitimate merchants out of the portfolio at the point of entry.`
|
|
140
|
+
|
|
141
|
+
### e. Recommendation Summary
|
|
142
|
+
|
|
143
|
+
Use this sentence **verbatim** — do not expand it or add per-domain detail:
|
|
144
|
+
|
|
145
|
+
> The Acquirer must address the identified control gaps and submit a remediation plan within 30 days. Visa will review the plan and schedule follow-up assessments as needed.
|
|
146
|
+
|
|
147
|
+
---
|
|
148
|
+
|
|
149
|
+
## Section 4: Observations Overview
|
|
150
|
+
|
|
151
|
+
**Audience: department managers / control owners.** Visa's standard Section 4 columns are retained; the **values** are drawn from the tracker (Priority is dropped — VARS has no severity-priority). This section is more detailed than Section 3.d — it gives the responsible owner a substantive picture of what is in place and what (if anything) to fix.
|
|
152
|
+
|
|
153
|
+
| # | Section Title | Compliance Status | Findings and Comments | Revision after Remediation Completion |
|
|
154
|
+
|---|------------------------------------|-------------------|-----------------------|---------------------------------------|
|
|
155
|
+
| 1 | Risk Appetite and Policy Framework | | | |
|
|
156
|
+
| 2 | Written Agreement | | | |
|
|
157
|
+
| 3 | Onboarding | | | |
|
|
158
|
+
| 4 | Monitoring | | | |
|
|
159
|
+
| 5 | Chargebacks/Disputes | | | |
|
|
160
|
+
| 6 | Data Integrity/Quality | | | |
|
|
161
|
+
| 7 | Data Security | | | |
|
|
162
|
+
| 8 | Network and Scheme Compliance | | | |
|
|
163
|
+
| 9 | Regulatory Risk | | | |
|
|
164
|
+
|
|
165
|
+
**Note on numbering:** the official 2025 template skips row 9 and labels Regulatory
|
|
166
|
+
Risk as #10. That is a known artifact in the source document. Use sequential 1–9 here
|
|
167
|
+
unless the Visa engagement lead requires the legacy numbering.
|
|
168
|
+
|
|
169
|
+
**Third Party Agent row.** When the ATPA (Acquirer Third Party Agent) archetype is in
|
|
170
|
+
scope, rows 1–9 cover the Acquirer's own (AACQ) controls and **all ATPA controls are
|
|
171
|
+
consolidated into an additional row 10, "Third Party Agent"** — rather than scattering
|
|
172
|
+
TPA controls across the AACQ sub-domains (so e.g. a TPA-agreement gap does not pull the
|
|
173
|
+
"Written Agreement" or "Onboarding" rows down). Omit row 10 when ATPA is out of scope.
|
|
174
|
+
|
|
175
|
+
**Compliance Status values:** Satisfactory / Improvement Recommended / Unsatisfactory / N/A — the tracker's Control Effectiveness Rating. A sub-domain takes the **worst** rating among its controls (any Unsatisfactory ⇒ Unsatisfactory; else any Improvement Recommended ⇒ Improvement Recommended; else Satisfactory; N/A only if every control is N/A).
|
|
176
|
+
**Findings and Comments:** written as an **inline auditor narrative** — flowing prose (no bold sub-headings) that conveys, in order, what was **observed** (the controls and practices in place), the **finding** (the rating and any mandatory gaps), and **comments** (recommendations and scoping notes such as N/A controls). Describe the controls in the report's **own words**; do **not** cite the underlying evidence documents, clauses, attestation numbers, or specific samples — that detail lives in the tracker (Section 5), and repeating it here duplicates the tracker. Lightweight control-ID cross-references (e.g. `AACQ.C8.1`) may be included as pointers. The **Actions Required** and **Recommendations** items must be reproduced **verbatim — word for word — from the tracker's Issue Description** (only the observations narrative is in the report's own words); put each item on its own line so they stay visible. For a fully **Satisfactory** row, close with `No remediation required.` When rendering to DOCX/PDF, each `<br>`-separated line in this cell must appear on its own line — see the rendering note in `SKILL.md` (a plain pandoc table conversion collapses them).
|
|
177
|
+
|
|
178
|
+
---
|
|
179
|
+
|
|
180
|
+
## Section 5: Detailed Information
|
|
181
|
+
|
|
182
|
+
> Refer to the accompanying *VARS Control Testing and Remediation Tracking* spreadsheet
|
|
183
|
+
> (including HIR template) for detailed information on all controls tested during this
|
|
184
|
+
> VARS review.
|
|
185
|
+
|
|
186
|
+
If the audit produced a Markdown tracker (e.g., from the `compliance-audit` skill),
|
|
187
|
+
note its filename here and confirm it has been converted to / synchronized with the
|
|
188
|
+
official Visa Excel tracker.
|
|
189
|
+
|
|
190
|
+
---
|
|
191
|
+
|
|
192
|
+
## Section 6: Next Steps
|
|
193
|
+
|
|
194
|
+
Describe required remediation timeline, due dates, next review schedule, and any
|
|
195
|
+
follow-up commitments. Close with:
|
|
196
|
+
|
|
197
|
+
> For any questions or additional information regarding this report, please send an
|
|
198
|
+
> email to **VIRPregistration@visa.com**.
|
|
199
|
+
|
|
200
|
+
*— End of Report —*
|
|
201
|
+
|
|
202
|
+
---
|
|
203
|
+
|
|
204
|
+
## Mapping audit findings → VARS report
|
|
205
|
+
|
|
206
|
+
When converting `compliance-audit` tracker output into this report:
|
|
207
|
+
|
|
208
|
+
| Tracker field | Report destination |
|
|
209
|
+
|------------------------------|---------------------------------------------------------------------------|
|
|
210
|
+
| Sub-domain / Category (AACQ) | Section 4 rows 1–9 + Section 3.d bullet; ATPA controls → the Third Party Agent row (Section 4 row 10) + its 3.d bullet |
|
|
211
|
+
| Control Effectiveness Rating | Section 4 "Compliance Status" (worst rating across the row's controls) + the row's Section 3.d posture |
|
|
212
|
+
| Observations | Section 4 "Findings and Comments" — re-narrated in the report's **own words** (no source-document/clause/sample citations) |
|
|
213
|
+
| Issue Description (Actions Required / Recommendations) | Section 4 "Findings and Comments" — reproduced **verbatim, word for word** (not paraphrased) |
|
|
214
|
+
| Evidence / per-control detail / document citations | Excel tracker (referenced from Section 5) — not repeated in the report |
|
|
215
|
+
| Remediation owner/ETA | Section 6 |
|
|
216
|
+
|
|
217
|
+
For **Section 3.d** (executive), aggregate each sub-domain into a 2–3 sentence
|
|
218
|
+
business-oriented posture under an overall headline. For **Section 4** (department
|
|
219
|
+
managers), keep one row per sub-domain (plus the Third Party Agent row when ATPA is in
|
|
220
|
+
scope): the Findings and Comments cell is an inline observed → finding → comments
|
|
221
|
+
narrative in the report's own words, the Actions Required / Recommendations are verbatim
|
|
222
|
+
from the tracker, and the Compliance Status is the worst rating across the row's
|
|
223
|
+
controls. Per-control evidence and citations belong in the companion Excel tracker, not
|
|
224
|
+
the report.
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: doc-to-md
|
|
3
|
+
description: "Convert documents (PDF, DOCX, PPTX, XLSX, images) to Markdown so agents can read them. Use as the preprocessing step whenever binary files need to enter agent context — contract review, compliance audit, document analysis, evidence review."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# doc-to-md
|
|
7
|
+
|
|
8
|
+
Preprocess binary documents into readable markdown before agent analysis.
|
|
9
|
+
|
|
10
|
+
## Quick Use
|
|
11
|
+
|
|
12
|
+
```bash
|
|
13
|
+
# Single file
|
|
14
|
+
python3 {baseDir}/scripts/convert.py policy.docx
|
|
15
|
+
|
|
16
|
+
# Single file → specific output dir
|
|
17
|
+
python3 {baseDir}/scripts/convert.py merchant-agreement.pdf ./evidence-md/
|
|
18
|
+
|
|
19
|
+
# Whole directory
|
|
20
|
+
python3 {baseDir}/scripts/convert.py ./evidence-docs/ ./evidence-md/
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Output: `<output_dir>/<original_stem>.md`. Exits 0 if all succeed, 1 if any fail.
|
|
24
|
+
|
|
25
|
+
## Supported Formats
|
|
26
|
+
|
|
27
|
+
| Format | Extensions | Engine |
|
|
28
|
+
|--------|-----------|--------|
|
|
29
|
+
| PDF | `.pdf` | `pdftotext` (primary) → `markitdown` (fallback) |
|
|
30
|
+
| Word | `.docx` | markitdown |
|
|
31
|
+
| PowerPoint | `.pptx` | markitdown |
|
|
32
|
+
| Excel | `.xlsx`, `.xls` | markitdown |
|
|
33
|
+
| HTML | `.html`, `.htm` | markitdown |
|
|
34
|
+
| Images | `.jpg`, `.jpeg`, `.png`, `.gif`, `.webp`, `.bmp`, `.tiff` | markitdown |
|
|
35
|
+
|
|
36
|
+
**PDF engine:** `pdftotext` (poppler-utils) produces cleaner output for text-layer PDFs — better whitespace, more compact. Falls back to markitdown if pdftotext is unavailable or returns empty output. `pdftotext` is pre-installed system-wide (`/usr/bin/pdftotext`).
|
|
37
|
+
|
|
38
|
+
Unsupported extensions are silently skipped (not a failure).
|
|
39
|
+
|
|
40
|
+
## Edge Cases
|
|
41
|
+
|
|
42
|
+
**Scanned PDFs (no text layer)**
|
|
43
|
+
Script outputs a placeholder comment: `<!-- doc-to-md: no text extracted ... -->`. To extract text from scanned PDFs, use the `image` tool with vision model to OCR the relevant pages separately.
|
|
44
|
+
|
|
45
|
+
**Password-protected PDFs**
|
|
46
|
+
markitdown will fail with a decryption error. Ask the user to remove the password first (`qpdf --decrypt input.pdf output.pdf`).
|
|
47
|
+
|
|
48
|
+
**Large files**
|
|
49
|
+
No chunking needed — conversion runs in one pass. If the resulting markdown is very large, split by heading before loading into context:
|
|
50
|
+
```bash
|
|
51
|
+
# Extract content between two top-level headings (adjust pattern to match actual heading text)
|
|
52
|
+
awk '/^# Section Name/{f=1} /^# /{if(f && !/Section Name/)exit} f' file.md
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
## Setup
|
|
56
|
+
|
|
57
|
+
markitdown is pre-installed at `~/.local/lib/python3-markitdown`. The script adds this path automatically — no action needed unless the environment changes.
|
|
58
|
+
|
|
59
|
+
If the module is missing (ImportError on run):
|
|
60
|
+
```bash
|
|
61
|
+
uv pip install --system --target ~/.local/lib/python3-markitdown "markitdown[all]"
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
## Integration
|
|
65
|
+
|
|
66
|
+
Used as a preprocessing step by multiple skills. Call via a subagent:
|
|
67
|
+
|
|
68
|
+
```
|
|
69
|
+
Convert all documents in <input-dir>/ to markdown using the doc-to-md skill.
|
|
70
|
+
Run: python3 {baseDir}/scripts/convert.py <input-dir>/ <output-dir>/
|
|
71
|
+
Report which files succeeded and which failed (if any).
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
**Skills that use this:**
|
|
75
|
+
- `compliance/compliance-audit` — Step 0 evidence preprocessing
|
|
76
|
+
- `contract-review` — Step 1 contract file conversion
|
|
77
|
+
- `utils/mandate-preprocess` — Step 1 mandate document conversion
|