@raishin/vanguard-frontier-agentic 2.10.0 → 2.13.0

package/skills/sap/sap-transformation-portfolio-triage-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Transformation Portfolio Triage Review"
+  short_description: "Advisory triage of an SAP transformation program: workstream prioritization, dependency mapping, readiness gating across S/4HANA, BTP, integration, and security workstreams, and RAID log review."
+  default_prompt: "Use $sap-transformation-portfolio-triage-review to triage the provided SAP transformation program portfolio. Classify each workstream by domain (S/4HANA conversion, BTP platform, integration, security, data migration, change management), assess cross-workstream dependencies and sequencing, evaluate readiness gate completeness, review the RAID log for unowned or unresolved items, and classify findings by risk level (critical/high/medium/low). State evidence level for each finding and whether live project tool access is required."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/activate-methodology/sap-activate-methodology/workstreams"
+      description: "SAP Activate workstreams documentation — primary reference for workstream structure, phase sequencing, and readiness gate criteria"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-transformation-portfolio-triage-review/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "sap-transformation-portfolio-triage-review",
+  "name": "SAP Transformation Portfolio Triage Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Advisory triage of an SAP transformation program portfolio: workstream prioritization, dependency and risk mapping, value vs effort classification, readiness gating across S/4HANA, BTP, integration, and security workstreams, and RAID log assessment. Does not access live systems.",
+  "source_type": "original",
+  "category": "architecture",
+  "official_docs": [
+    "https://help.sap.com/docs/activate-methodology/sap-activate-methodology/sap-activate-methodology-guide",
+    "https://help.sap.com/docs/activate-methodology/sap-activate-methodology/workstreams",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/portfolio-and-project-management",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/project-management",
+    "https://support.sap.com/en/alm/sap-activate.html",
+    "https://help.sap.com/docs/s4hana-cloud/sap-s-4hana-cloud/fit-to-standard-analysis",
+    "https://help.sap.com/docs/activate-methodology/sap-activate-methodology/quality-gates"
+  ],
+  "security_notes": "Does not access live SAP systems, SAP Cloud ALM, project management tools, or transformation program repositories. Accepts only user-provided project plans, RAID logs, workstream charters, dependency maps, or written descriptions of the transformation program. Never request or accept SAP system credentials, Cloud ALM API tokens, Jira access tokens, or any live project tool authentication. Triage recommendations must be validated against the current program plan before communicating to stakeholders.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-transformation-portfolio-triage-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-transformation-portfolio-triage-review/references/official-sources.md

@@ -0,0 +1,71 @@
+# Official sources — SAP Transformation Portfolio Triage Review
+
+Use this reference when grounding workstream classification, phase sequencing, readiness gate criteria, RAID assessment, and SAP Activate methodology alignment.
+
+**Evidence level**: documentation-based (SAP Activate methodology, SAP Cloud ALM, SAP Help Portal). No live-system evidence is collected by this skill.
+
+## SAP Activate methodology
+
+- SAP Activate Methodology Guide
+  https://help.sap.com/docs/activate-methodology/sap-activate-methodology/sap-activate-methodology-guide
+  source_owner: SAP SE
+  topic_supported: SAP Activate phases (Discover, Prepare, Explore, Realize, Deploy, Run), phase exit criteria, accelerators, methodology principles
+  why_needed: Primary methodology reference for assessing whether transformation workstreams are sequenced correctly relative to SAP Activate phase gates
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Activate Workstreams
+  https://help.sap.com/docs/activate-methodology/sap-activate-methodology/workstreams
+  source_owner: SAP SE
+  topic_supported: Standard SAP Activate workstream taxonomy, workstream-level task lists, dependencies between workstreams, workstream ownership
+  why_needed: Defines the canonical workstream structure against which user-provided program workstreams are classified and assessed for completeness
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Activate Quality Gates
+  https://help.sap.com/docs/activate-methodology/sap-activate-methodology/quality-gates
+  source_owner: SAP SE
+  topic_supported: Quality gate criteria per SAP Activate phase, exit checklist items, gate review process, readiness evidence requirements
+  why_needed: Defines the readiness gate standard for each phase exit — required to assess whether workstreams have sufficient readiness evidence before proceeding
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Activate Methodology (SAP Support Portal)
+  https://support.sap.com/en/alm/sap-activate.html
+  source_owner: SAP SE
+  topic_supported: SAP Activate roadmap viewer, accelerator catalog, methodology updates, links to scenario-specific roadmaps (S/4HANA, cloud, hybrid)
+  why_needed: Entry point for scenario-specific roadmaps and accelerators — required when the transformation scenario (greenfield, brownfield, selective data transition) affects workstream structure
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## S/4HANA fit-to-standard and scope
+
+- Fit-to-Standard Analysis
+  https://help.sap.com/docs/s4hana-cloud/sap-s-4hana-cloud/fit-to-standard-analysis
+  source_owner: SAP SE
+  topic_supported: Fit-to-standard workshop process, scope item selection, gap identification, delta design output as input to extensibility decisions
+  why_needed: Defines the mandatory sequence of fit-to-standard before solution design and configuration — key to identifying S/4HANA workstream sequencing violations
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM program management
+
+- SAP Cloud ALM Portfolio and Project Management
+  https://help.sap.com/docs/cloud-alm/applicationhelp/portfolio-and-project-management
+  source_owner: SAP SE
+  topic_supported: Portfolio-level program structure in SAP Cloud ALM, project hierarchy, milestone tracking, cross-project dependency visibility
+  why_needed: Reference for organizations using SAP Cloud ALM as their program management tool — enables assessment of whether program artifacts are being captured correctly
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Cloud ALM Project Management
+  https://help.sap.com/docs/cloud-alm/applicationhelp/project-management
+  source_owner: SAP SE
+  topic_supported: Task management, RAID log management, project timeline, workstream progress tracking, deliverable status within SAP Cloud ALM
+  why_needed: Defines the SAP-native approach to RAID log management and project task tracking — required when assessing whether the user's RAID log structure aligns with SAP Cloud ALM conventions
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Activate methodology and SAP Cloud ALM documentation describe the designed transformation methodology and program management approach. They do not prove what workstreams exist in the user's program, how dependencies are managed, or whether readiness gates have been passed. Users must supply project plans, RAID logs, workstream charters, or architecture decision records for concrete triage assessment.

package/skills/sap/sap-transformation-portfolio-triage-review/references/safety-checklist.md

@@ -0,0 +1,36 @@
+# Safety checklist — SAP Transformation Portfolio Triage Review
+
+Use before making any triage recommendation, especially for findings that affect workstream sequencing, dependency resolution, RAID escalation, or readiness gate decisions with go-live implications.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP system, SAP Cloud ALM tenant, project management tool, or transformation program repository. This skill reviews artifacts only.
+- Do not accept or request SAP system credentials, SAP Cloud ALM API tokens, Jira access tokens, or any live project tool authentication.
+- Do not recommend changing workstream sequencing without first understanding which downstream workstreams depend on the current sequence. Sequence changes in a running program have cascade effects.
+- Do not classify a RAID item as low risk without checking whether it appears in the critical path. A technically low-risk issue on the critical path is a program risk.
+- Do not recommend descoping a workstream without first confirming what regulatory, contractual, or go-live dependency that workstream satisfies.
+- Do not use inference alone to conclude that a workstream is blocked. Blocking dependency findings must be traceable to user-provided evidence or official SAP Activate methodology.
+- Do not conflate methodology phase with calendar phase. A program may label its phases differently from SAP Activate. Identify the equivalent phase before applying readiness gate criteria.
+
+## What people get wrong
+
+- **Starting configuration before fit-to-standard is complete**: This is the most common S/4HANA workstream sequencing error. Configuration decisions made before fit-to-standard workshops are complete are built on unvalidated scope and frequently require rework.
+- **Treating integration as a sub-workstream of S/4HANA**: Integration is a cross-cutting workstream that must be scoped, designed, and tested independently. Programs that subordinate integration to the S/4HANA track consistently underplan interface inventory and integration testing.
+- **RAID log treated as a status report rather than a risk instrument**: RAID logs that record issues without mitigation plans or owners are governance documents, not risk management tools. Flag this pattern explicitly.
+- **Readiness gates treated as checkboxes rather than gates**: A quality gate where all items are marked complete but supporting evidence is not reviewed is not a gate — it is a milestone stamp. Push back on programs that cannot produce evidence for gate criteria.
+- **Change management starting in Deploy phase**: Change management that begins during deployment is structurally too late. Stakeholder engagement and training needs analysis must begin in Prepare or Explore at the latest.
+- **Data migration treated as a Deploy-phase activity**: Data migration preparation (extraction, cleansing, transformation design) must begin in Explore. Programs that start data migration in Realize are at high risk of cutover failure.
+- **Underestimating security and compliance workstream duration**: Authorization concept design, SoD matrix definition, and GRC configuration are consistently underestimated. They depend on fit-to-standard output and take longer than expected in complex organizations.
+
+## When to push back
+
+- Push back when the user asks to triage a program without providing any program artifact (project plan, RAID log, workstream charter, or dependency map). Triage from memory alone is inference, not assessment.
+- Push back when the user asks to confirm a workstream is on track without providing evidence of readiness gate completion.
+- Push back when a request requires live access to SAP Cloud ALM, Jira, or another project tool — state clearly that live inspection is out of scope and ask the user to supply the relevant exports or descriptions.
+- Push back when the user asks to recommend a specific go-live date without providing a complete view of the critical path across workstreams.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Activate methodology, SAP Cloud ALM program management docs, or official SAP transformation guidance
+- `user-provided evidence` — project plans, RAID logs, workstream charters, dependency maps, or steering decks provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such

package/skills/sap/sap-transformation-portfolio-triage-review/references/workflow-and-output.md

@@ -0,0 +1,69 @@
+# Workflow and output contract — SAP Transformation Portfolio Triage Review
+
+Use this reference for workstream classification, dependency assessment, readiness gate evaluation, RAID log review, and output formatting.
+
+## Workstream classification taxonomy
+
+| Workstream domain | Scope | Typical triage findings |
+|-------------------|-------|------------------------|
+| `s4hana-conversion` | System conversion, greenfield, or selective data transition; fit-to-standard workshops; configuration; unit and integration testing; cutover | Fit-to-standard skipped, configuration started before gap analysis, cutover plan missing, no regression test scope defined |
+| `btp-platform` | BTP account model, subaccount design, environment provisioning, extensibility foundation | BTP provisioned after S/4HANA go-live planning, extensibility design not aligned to clean core decisions, no BTP governance model defined |
+| `integration` | Integration architecture, middleware selection, API design, interface inventory, integration testing | Interface inventory incomplete, integration platform not selected before S/4HANA configuration, no end-to-end integration test plan |
+| `data-migration` | Legacy data extraction, cleansing, transformation, loading, reconciliation, data archiving | Data migration started too late, no data quality baseline established, reconciliation criteria undefined |
+| `security-and-compliance` | Role design, authorization concept, GRC, SoD matrix, audit readiness, regulatory compliance | Authorization concept not started before configuration, SoD rules not defined, no security acceptance criteria for go-live |
+| `change-management` | Stakeholder engagement, training design, communication plan, readiness assessment, hypercare | Change management not started until Deploy phase, no training needs analysis, hypercare plan missing |
+| `infrastructure` | Hosting, network, connectivity, SAP infrastructure readiness, cloud migration | Infrastructure sizing not complete before Realize, connectivity to legacy systems not tested, DR not defined |
+
+## Risk severity classification
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Dependency or sequencing failure that directly threatens the program go-live date, a regulatory deadline, or creates a mandatory rework loop (e.g., configuration started without fit-to-standard, cutover planned without data migration reconciliation) |
+| `high` | Workstream without a defined readiness gate entering the next phase, unresolved cross-workstream blocking dependency, RAID risk with no mitigation plan and high program impact |
+| `medium` | RAID gap (unowned risk, undated assumption, issue without resolution path), workstream prioritization imbalance (high-value workstream under-resourced), missing but non-blocking dependency |
+| `low` | Best practice deviation in program structure (no naming convention, inconsistent workstream reporting cadence, RAID log not reviewed in more than two steering cycles) |
+
+## RAID log assessment criteria
+
+For each RAID item category:
+
+- **Risks**: Does each risk have an owner, a likelihood and impact rating, a mitigation plan, and a review date? Unmitigated high-impact risks with no owner are `high` findings.
+- **Assumptions**: Does each assumption have an owner and a validation date? Stale assumptions (no validation in more than one SAP Activate phase) are `medium` findings.
+- **Issues**: Does each issue have an owner, a target resolution date, and a status? Issues open beyond the resolution date with no escalation are `high` findings.
+- **Decisions**: Is each decision recorded with the decision maker, the date, and the rationale? Undocumented decisions create ambiguity that manifests as rework in Realize and Deploy.
+
+## Readiness gate evaluation
+
+Per SAP Activate phase exit:
+
+| Phase exit | Key readiness evidence required |
+|------------|--------------------------------|
+| Prepare exit | Project charter signed, team mobilized, system landscape confirmed, sandbox provisioned |
+| Explore exit | Fit-to-standard workshops complete, gap list approved, extensibility decisions recorded, integration inventory complete |
+| Realize exit | Configuration complete, unit test sign-off, integration test complete, data migration dry run executed, training materials drafted |
+| Deploy exit | User acceptance testing sign-off, cutover rehearsal complete, hypercare plan approved, go/no-go criteria met |
+
+A workstream that advances to the next phase without completing the prior phase exit evidence set is a `high` readiness gate finding.
+
+## Workflow
+
+1. **Receive artifacts** — project plan, RAID log, workstream charters, dependency maps, steering committee decks, or program descriptions.
+2. **Classify each workstream** by domain.
+3. **Map dependencies** — identify predecessor, shared-outcome, and cross-workstream integration dependencies.
+4. **Assess readiness gates** per SAP Activate phase exit for each workstream.
+5. **Review RAID log** for completeness, ownership, and resolution status.
+6. **Classify findings** by risk level (critical / high / medium / low).
+7. **Prioritize** — critical sequencing or gate failures first; then high dependency and RAID issues; then medium gaps; then low best-practice items.
+8. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Workstream domain and specific triage finding
+2. Evidence label (documentation-based / user-provided evidence / inference)
+3. Risk level per finding (critical / high / medium / low)
+4. Recommended action (resequence, add readiness gate, escalate RAID item, restructure dependency, adjust resourcing)
+5. Dependency chain affected (if applicable)
+6. Prioritized remediation sequence
+7. Escalation trigger if live project tool access is required to confirm the finding

package/skills/sap/sap-treasury-cash-risk-review/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: sap-treasury-cash-risk-review
+description: Review SAP Treasury and Risk Management (TRM) and Cash Management configurations: cash position and liquidity forecasting controls, bank account management (BAM) governance, in-house cash and payment factory design, hedge and exposure management controls, fraud prevention in payment processing, and segregation of duties across treasury operations. Flags control gaps in cash visibility, unauthorized payment release paths, hedge documentation deficiencies, bank account governance weaknesses, and fraud control bypass risks. Does not execute payments, trades, or hedges, and does not access any live treasury or banking system.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: finance
+  lifecycle: experimental
+---
+
+# SAP Treasury Cash Risk Review
+
+## Purpose
+
+Assess the control posture, configuration design, and governance quality of SAP Treasury and Risk Management (TRM) and SAP Cash Management implementations within S/4HANA. Evaluate cash position and liquidity forecasting controls by reviewing cash management configuration, memo record governance, bank statement processing automation (electronic bank statement / MultiCash / EBAM), liquidity item hierarchy design, and whether cash position reporting provides an accurate and timely view of available liquidity. Review bank account management (BAM) governance by assessing SAP Bank Account Management configuration: bank account master data governance, account opening and closing approval workflows, signatory management, bank account authorization controls, and whether unauthorized bank accounts can be created or modified without a four-eyes approval. Assess in-house cash (IHC) and payment factory design by evaluating in-house bank configuration, internal account structure, payment request routing controls, netting design, and whether the payment factory aggregation logic prevents unauthorized outbound payment aggregation. Evaluate hedge and exposure management controls by reviewing financial instrument configuration (OTC derivatives, bonds, interest rate instruments), treasury position management, exposure determination logic, hedge designation and documentation workflow (hedge accounting under IFRS 9 / IAS 39), ineffectiveness calculation, and whether hedge documentation gaps create audit or accounting risk. Assess payment processing fraud controls by reviewing dual-control configuration in payment approval (payment request status management, payment release authorization, bank communication management channel controls), SWIFT or host-to-bank connectivity governance, and whether a single user can initiate, approve, and release a payment to an external bank without a second authorized approver. Review segregation of duties across treasury operations by identifying combined authorization over cash position manipulation, payment release, bank account management, and financial instrument trading. Does not connect to or mutate any live SAP S/4HANA Treasury, banking, or trading system. Never executes payments, trades, hedges, settlements, or bank transfers.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review SAP S/4HANA Cash Management configuration: cash position structure, liquidity item hierarchy design, memo record governance, bank statement processing (electronic bank statement / BAI2 / MT940 / CAMT), cash concentration and zero-balancing configuration, and whether cash position reporting provides timely and complete visibility over the group's cash,
+- assess SAP Bank Account Management (BAM) governance: bank account master data management, account lifecycle workflow (open, modify, close), signatory management and authority matrix, bank account authorization objects, four-eyes approval configuration for account creation and modification, and whether unauthorized bank accounts can be established or altered without a documented approval chain,
+- evaluate SAP in-house cash (IHC) configuration and payment factory design: in-house bank structure, internal account assignment, payment request routing logic, netting and settlement controls, payment factory aggregation governance, and whether the in-house cash configuration allows internal payment requests to be aggregated and released externally without dual-control authorization,
+- review SAP Treasury and Risk Management (TRM) financial instrument configuration: instrument type design (OTC derivatives, bonds, interest rate swaps, FX forwards, commodity derivatives), transaction flow configuration, position management controls, settlement processing governance, and whether the instrument configuration supports the entity's stated hedging strategy and accounting policy,
+- assess hedge and exposure management controls: exposure determination source configuration (SD open items, MM purchase orders, financial forecasts), hedge designation workflow, hedge documentation completeness under IFRS 9 or IAS 39, ineffectiveness testing configuration, hedge accounting valuation controls, and whether hedge documentation gaps expose the entity to derecognition or restatement risk,
+- evaluate payment processing fraud controls: dual-control configuration in SAP payment approval (payment request status transitions, payment release authorization objects, bank communication manager channel controls), SWIFT connectivity governance (SWIFT Alliance, bank communication management), host-to-bank file security, and whether a single treasury user has combined authority to create, approve, and release a payment run to an external bank,
+- identify SoD exposures across treasury operations: combined authority to manage bank accounts and release payments; combined authority to create financial instruments and execute settlement; combined authority to modify cash position memo records and release payment requests; combined authority over FX exposure determination and hedge instrument execution; and whether treasury SoD controls are enforced at the SAP authorization object level or only at the process level,
+- review treasury reporting and compliance controls: regulatory reporting configuration (EMIR, FRTB, Dodd-Frank position reporting), audit trail completeness for financial instrument transactions, treasury accounting entries in the general ledger, mark-to-market valuation controls, and whether treasury accounting is reconciled to the FI general ledger on a daily or period-end basis.
+
+## When not to use
+
+- When the user needs live inspection of cash positions, bank account balances, outstanding payment runs, or financial instrument positions — this skill accepts only user-provided configuration summaries, authorization object exports, bank account master data reports, hedge documentation summaries, payment run logs, or written descriptions of the treasury landscape.
+- When the request is about SAP S/4HANA Finance Accounts Payable (FI-AP) payment run configuration (F110) without a treasury dual-control or fraud control angle — use `sap-finance-fico-controls-review` for FI-AP payment run controls in the FI context.
+- When the request concerns SAP Ariba supplier payments or procurement-driven payment processing without a treasury management system angle — use `sap-procurement-ariba-value-leakage-review` for procurement payment controls.
+- When the request is specifically about SAP GRC Access Control ruleset design for TRM transaction codes — use `sap-security-iam-grc-sod-review` for GRC ruleset assessment; this skill identifies treasury SoD exposures in process terms rather than reviewing the GRC system itself.
+- When the request concerns SAP Analytics Cloud or SAP Datasphere treasury dashboards rather than the underlying TRM/Cash Management control configuration — visual analytics design is out of scope for this skill.
+
+## Does not touch live systems
+
+This skill operates on user-provided configuration descriptions, bank account master data reports, authorization object exports, payment run logs, hedge documentation summaries, in-house cash structure descriptions, bank statement processing configuration notes, financial instrument setup descriptions, or written descriptions of the treasury and cash management landscape. It does not connect to any SAP S/4HANA Treasury system, SAP Bank Communication Manager, SWIFT network, banking portal, Fiori launchpad, SAP GUI session, or backend RFC. It does not initiate, approve, release, cancel, or modify any payment, bank transfer, trade, hedge, settlement, or financial instrument transaction.
+
+**This skill never executes payments, trades, or hedges.** No payment run initiation, no payment release, no bank transfer, no FX trade execution, no hedge designation or de-designation, no financial instrument creation or settlement, and no bank account opening or closing is performed or recommended as a direct action in this skill's execution path. All remediation recommendations describe configuration, authorization, or process design changes to be implemented and tested in a non-production environment.
+
+## Lean operating rules
+
+- Classify treasury control findings before recommending. Every finding must be assigned to a treasury control domain (cash position and liquidity / bank account management / in-house cash and payment factory / financial instruments / hedge and exposure management / payment fraud controls / treasury SoD) before a remediation path is proposed.
+- Single-user payment release authority is a first-order fraud risk. Any configuration allowing one user to create, approve, and release a payment to an external bank account without a second authorized approver is a `critical` finding. Escalate before other remediation.
+- Unauthorized bank account creation is a high-severity governance gap. A BAM configuration that allows bank account records to be created or modified without a documented four-eyes approval workflow exposes the entity to unauthorized external payment destination risk. Classify as `high`.
+- Hedge documentation deficiency creates accounting and audit risk. Missing or incomplete hedge designation documentation under IFRS 9 or IAS 39 — including missing effectiveness testing results, incomplete hedge relationship designations, or undocumented risk component identification — is a `high` finding that may trigger derecognition or restatement.
+- Cash position accuracy depends on memo record governance. Memo records that can be created or modified without authorization controls distort the cash position view and may support fraudulent cash concentration decisions. Assess memo record authorization as part of cash position review.
+- Payment factory aggregation requires dual-control verification. In-house cash payment factories that aggregate and release external payments must enforce dual-control at the aggregation stage — not only at the individual payment request stage. A single approver at the aggregation level with no second reviewer is a fraud control gap.
+- Treasury SoD must be enforced at the SAP authorization object level. Process-level SoD descriptions without corroborating SAP authorization object evidence (e.g., F_PAYR_BUK, F_REGU_BUK, TR_BANKI, TR_BANKA) are classified as `inference` and must be confirmed with user-provided role exports.
+- Evidence from user-provided artifacts or official SAP S/4HANA Treasury and Cash Management documentation takes precedence over inference.
+- Load only the reference needed for the treasury control domain under review.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP S/4HANA Treasury and Risk Management, SAP Cash Management, SAP Bank Account Management, SAP Bank Communication Manager, or SAP Help Portal TRM documentation
+- `user-provided evidence` — authorization object exports, bank account master data reports, payment run logs, hedge documentation summaries, in-house cash configuration descriptions, bank statement processing notes, financial instrument setup exports, or written descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no SAP S/4HANA RFC call, Fiori OData API invocation, SAP GUI session, BAPI execution, SWIFT network connection, banking portal access, or direct database query in this skill's execution path. Users must supply configuration summaries, authorization object exports, bank account reports, payment run logs, hedge documentation notes, or written descriptions of their treasury and cash management landscape for this skill to review.
+
+**This skill never executes payments, trades, or hedges.** Recommendations describing remediation always apply to configuration, authorization, or process design — not to direct payment execution, trade entry, hedge designation, bank account creation, or financial instrument settlement.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — treasury control finding taxonomy, severity assignment, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common treasury control review mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP S/4HANA Treasury and Risk Management, Cash Management, Bank Account Management, and payment fraud control documentation.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: treasury control domain(s) affected (cash position and liquidity / bank account management / in-house cash and payment factory / financial instruments / hedge and exposure management / payment fraud controls / treasury SoD) and specific finding(s) per domain.
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: critical (single-user payment release enabling external payment fraud; combined create-approve-release authority for external payments; unauthorized bank account creation path) / high (BAM four-eyes approval gap; hedge documentation deficiency creating derecognition risk; memo record manipulation without authorization; in-house cash aggregation without dual-control; treasury SoD in instrument creation and settlement) / medium (cash position accuracy gap from memo record governance weakness; bank statement processing automation gap; liquidity hierarchy design flaw; ineffectiveness testing configuration gap) / low (best practice deviation in financial instrument type design or reporting configuration).
+- **Recommended action**: specific configuration or process remediation per finding (dual-control payment release configuration, BAM four-eyes approval workflow implementation, memo record authorization tightening, hedge designation workflow correction, in-house cash dual-control at aggregation, treasury SoD role separation, bank communication manager channel security, etc.).
+- **Refusal / escalation triggers**: if single-user external payment release authority or unauthorized bank account creation path is found, escalate to the treasury, audit, and GRC team before any further payments are processed or bank accounts are modified. If a finding requires live SAP Treasury system inspection, state that clearly and ask the user to supply the relevant export or description. This skill never executes payments, trades, or hedges under any circumstances.
+- **Business impact**: external payment fraud exposure, unauthorized cash transfer risk, hedge accounting restatement risk under IFRS 9 or IAS 39, regulatory reporting gap (EMIR, Dodd-Frank), bank account governance failure, audit finding risk, liquidity misstatement risk.
+- **Next verification step**: confirm recommended configuration changes against the user's current SAP S/4HANA Treasury and Cash Management setup in a non-production system before promoting to production.

package/skills/sap/sap-treasury-cash-risk-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Treasury Cash Risk Review"
+  short_description: "Review SAP Treasury and Risk Management (TRM) and Cash Management controls: cash position and liquidity, bank account management governance, in-house cash and payment factory dual-control, hedge and exposure management, payment fraud prevention, and treasury SoD. Does not execute payments, trades, or hedges, and does not access live treasury or banking systems."
+  default_prompt: "Use $sap-treasury-cash-risk-review to assess the provided SAP Treasury and Cash Management control configuration. Classify each finding by treasury control domain (cash position and liquidity, bank account management, in-house cash and payment factory, financial instruments, hedge and exposure management, payment fraud controls, treasury SoD), assign a risk level (critical/high/medium/low), and recommend specific remediation actions. Flag any single-user external payment release authority or unauthorized bank account creation path for immediate escalation. State evidence level (documentation-based, user-provided, inference) and confirm that no live treasury system access, payment execution, trade entry, or hedge designation is required or performed."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/cash-management"
+      description: "SAP S/4HANA Cash Management documentation — primary reference for cash position and liquidity controls review"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-treasury-cash-risk-review/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "sap-treasury-cash-risk-review",
+  "name": "SAP Treasury Cash Risk Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP Treasury and Risk Management (TRM) and Cash Management controls: cash position and liquidity, bank account management governance, in-house cash and payment factory dual-control, hedge and exposure management, payment fraud prevention, and treasury SoD. Does not execute payments, trades, or hedges, and does not access live treasury or banking systems.",
+  "source_type": "original",
+  "category": "finance",
+  "official_docs": [
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/cash-management",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/bank-account-management",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/in-house-cash",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/treasury-and-risk-management",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/hedge-management-and-accounting",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/bank-communication-management",
+    "https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/liquidity-management"
+  ],
+  "security_notes": "Does not access live SAP S/4HANA Treasury systems, SAP Bank Communication Manager, SWIFT networks, banking portals, Fiori launchpads, SAP GUI sessions, or any production treasury or banking database. Accepts only user-provided configuration exports, authorization object summaries, bank account master data reports, payment run logs, hedge documentation summaries, or written descriptions of the treasury and cash management landscape. Never request or accept SAP logon credentials, RFC connection details, SWIFT credentials, banking portal access, or direct database connectivity. Never initiates, approves, releases, or modifies any payment, bank transfer, trade, hedge, settlement, or financial instrument. Critical payment fraud findings must be escalated to the treasury, audit, and GRC team — this skill does not authorize access changes or close audit findings.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-treasury-cash-risk-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-treasury-cash-risk-review/references/official-sources.md

@@ -0,0 +1,79 @@
+# Official sources — SAP Treasury Cash Risk Review
+
+Use this reference when grounding cash position and liquidity control assessment, bank account management governance review, in-house cash and payment factory dual-control evaluation, financial instrument configuration review, hedge and exposure management control analysis, payment fraud control assessment, and treasury SoD classification.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP S/4HANA Treasury and Risk Management documentation, SAP Cash Management documentation). No live-system evidence is collected by this skill.
+
+## Cash Management and liquidity planning
+
+- SAP S/4HANA Cash Management (On-Premise)
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/cash-management
+  source_owner: SAP SE
+  topic_supported: Cash position structure, liquidity item hierarchy, memo record management, bank statement processing (electronic bank statement, CAMT, BAI2, MT940), cash concentration, and short-term liquidity forecasting in SAP S/4HANA Cloud
+  why_needed: Primary reference for assessing cash position accuracy controls, liquidity hierarchy design completeness, and bank statement processing automation — required to classify cash visibility and memo record governance findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Bank Account Management (BAM)
+
+- SAP Bank Account Management (On-Premise)
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/bank-account-management
+  source_owner: SAP SE
+  topic_supported: Bank account master data management, bank account lifecycle (open, modify, close), signatory management, bank account authorization objects (TR_BANKI, TR_BANKA), four-eyes approval workflow for account maintenance in SAP S/4HANA On-Premise
+  why_needed: Authoritative reference for assessing bank account governance completeness — defines the BAM approval workflow and authorization object model used to classify unauthorized bank account creation and modification findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## In-house cash and payment factory
+
+- In-House Cash (On-Premise)
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/in-house-cash
+  source_owner: SAP SE
+  topic_supported: In-house bank configuration, internal account structure, payment request routing, netting and settlement controls, payment factory aggregation design, dual-control configuration in in-house cash payment processing
+  why_needed: Defines the in-house cash and payment factory control model — required to assess dual-control gaps in payment aggregation and release, and to classify in-house bank authorization SoD findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Treasury and Risk Management — financial instruments
+
+- SAP Treasury and Risk Management (On-Premise)
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/treasury-and-risk-management
+  source_owner: SAP SE
+  topic_supported: Financial instrument type configuration (OTC derivatives, bonds, interest rate instruments, FX forwards, commodity derivatives), transaction flow design, position management, settlement processing controls, and TRM authorization object model
+  why_needed: Primary reference for financial instrument configuration review — defines the instrument type, transaction flow, and position management model used to classify instrument configuration gaps and settlement control findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Hedge accounting and exposure management
+
+- Hedge Management and Hedge Accounting (On-Premise)
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/hedge-management-and-accounting
+  source_owner: SAP SE
+  topic_supported: Exposure determination source configuration, hedge designation and documentation workflow (IFRS 9 / IAS 39), hedge relationship type (fair value hedge, cash flow hedge, net investment hedge), effectiveness testing configuration, hedge accounting valuation controls in SAP S/4HANA Cloud
+  why_needed: Authoritative reference for hedge documentation completeness and effectiveness testing design — required to classify hedge designation gaps, derecognition risk, and IFRS 9 compliance findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Bank Communication Manager and payment fraud controls
+
+- SAP Bank Communication Management (On-Premise)
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/bank-communication-management
+  source_owner: SAP SE
+  topic_supported: Bank communication channel configuration, payment approval workflow (payment request status management, dual-control release), SWIFT connectivity governance, host-to-bank file security, payment status monitoring in SAP S/4HANA Cloud
+  why_needed: Defines the payment approval and bank communication control model — required to classify single-user payment release authority findings, dual-control gaps, and bank channel security weaknesses
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Liquidity management and forecasting
+
+- Liquidity Management (On-Premise)
+  https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/s4hana-finance/liquidity-management
+  source_owner: SAP SE
+  topic_supported: Short-term and medium-term liquidity planning configuration, liquidity item hierarchy design, liquidity forecast data source integration (AR, AP, Treasury deals), variance analysis and actuals comparison, liquidity planning approval and governance controls
+  why_needed: Defines the liquidity management planning and governance model — required to classify liquidity forecast completeness gaps, missing liquidity item coverage, and unmonitored cash flow variances
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal and S/4HANA Treasury and Cash Management documentation describe the designed control model and configuration options for TRM, Cash Management, BAM, IHC, and Bank Communication Manager. They do not prove what approval workflows are active in the user's system, whether BAM four-eyes approval is enforced, what authorization objects are assigned to treasury roles, or whether dual-control for payment release is configured. Users must supply authorization object exports, bank account master data reports, BAM configuration summaries, payment run logs, hedge documentation exports, or written descriptions of their treasury landscape for concrete assessment.

package/skills/sap/sap-treasury-cash-risk-review/references/safety-checklist.md

@@ -0,0 +1,38 @@
+# Safety checklist — SAP Treasury Cash Risk Review
+
+Use before making any treasury control remediation recommendation, especially for findings involving payment release authority, bank account management governance, hedge documentation, or treasury SoD.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP S/4HANA Treasury system, SAP Bank Communication Manager, SWIFT network, banking portal, Fiori launchpad, SAP GUI session, backend RFC, or production treasury or cash database. This skill reviews artifacts only.
+- Do not accept or request SAP logon credentials, RFC connection details, SWIFT credentials, banking portal access, or direct treasury database connectivity.
+- Do not initiate, approve, release, cancel, or modify any payment, bank transfer, trade, hedge, settlement, financial instrument, or bank account record. There is no payment run initiation, no payment release, no bank transfer, no FX trade execution, no hedge designation or de-designation, no financial instrument creation or settlement, and no bank account opening, modification, or closing in this skill's execution path. Recommendations always describe configuration and process design changes, not direct treasury actions.
+- Do not approve, close, or recommend closing an unmitigated critical payment fraud finding (single-user payment release, combined BAM/payment-release authority). Only the treasury, audit, and GRC team with appropriate authority can accept a treasury fraud risk. State this explicitly when critical findings are identified.
+- Do not recommend implementing configuration changes (BAM approval workflow, payment release authorization, bank communication channel settings) directly in a production SAP system. All recommendations must first be tested in a development or quality system.
+- Do not use memory alone to assert whether a specific combination of SAP treasury authorization objects (F_PAYR_BUK, F_REGU_BUK, TR_BANKI, TR_BANKA) creates an SoD conflict. Treasury SoD classification must be grounded in user-provided role exports, GRC conflict reports, or official SAP TRM documentation.
+- Do not assert hedge accounting compliance (IFRS 9 or IAS 39) from documentation review alone without confirming that hedge designation documentation, effectiveness testing results, and risk component identification are complete and up to date.
+
+## What people get wrong
+
+- **Treating payment approval workflow as sufficient without verifying authorization object separation**: A payment approval workflow configured in SAP Bank Communication Manager may require two approvers in the business process, but if both approvers share the same authorization object (F_PAYR_BUK with the same payment company code), one person can technically approve and release independently. Always verify authorization object scope matches the intended dual-control design.
+- **Overlooking BAM shadow bank accounts**: Bank accounts maintained in legacy banking master data (house bank accounts in FI-AP) outside the SAP Bank Account Management module may not be subject to BAM governance controls. A complete bank account governance review must cover both BAM-managed accounts and any residual house bank accounts in BNKA or T012 maintained outside BAM.
+- **Conflating hedge designation documentation with hedge accounting eligibility**: Completing IFRS 9 or IAS 39 designation documentation in SAP TRM does not automatically ensure hedge accounting eligibility. Effectiveness testing must also be completed, the hedging instrument must be a qualifying instrument, and the hedged item must be an eligible item. Documentation completeness and accounting eligibility are separate assessment dimensions.
+- **Missing in-house cash dual-control at aggregation**: In-house cash payment factories often have dual-control requirements at the individual payment request level but a single approver at the payment factory aggregation and external release level. The aggregation stage is where large outbound payments are formed — dual-control here is as important as at the request level.
+- **Assuming electronic bank statement automation eliminates cash position risk**: Automated bank statement processing (CAMT.053, MT940, BAI2) eliminates manual data entry errors but does not prevent delayed postings, processing failures, or incorrect liquidity item assignments. Cash position accuracy requires both automation and exception monitoring.
+- **Ignoring currency exposure from in-house bank internal accounts**: In-house bank internal accounts denominated in foreign currencies create FX exposure at the in-house bank entity level that may not be captured in the treasury FX exposure determination. Review whether in-house bank FX positions flow into the TRM exposure management module.
+- **Overlooking bank communication channel integrity**: SFTP or file-based host-to-bank transmission without digital signature or file integrity verification is a payment fraud enabler. A tampered payment file could redirect payment instructions between the SAP system and the bank without detection.
+
+## When to push back
+
+- Push back (and escalate) when single-user external payment release authority or combined BAM/payment-release authority is found — do not proceed with other recommendations until this is escalated to the treasury, audit, and GRC team.
+- Push back when the user asks to confirm treasury control compliance from memory alone without providing authorization object exports, bank account master data reports, or BAM configuration summaries.
+- Push back when the request requires live SAP Treasury system access (SAP GUI session, RFC call, Fiori OData API, SWIFT network inspection) — state clearly that live inspection is out of scope and ask the user to supply the relevant exports or summaries.
+- Push back when asked to initiate, approve, release, or modify any payment, trade, hedge, bank transfer, or bank account record — this is an absolute boundary and must be refused in all circumstances.
+- Push back when asked to approve or close a treasury audit finding or SoD risk without GRC/audit team authorization — this skill is advisory only.
+- Push back when hedge documentation deficiencies are identified but the user cannot provide the actual hedge designation documentation and effectiveness testing results — do not accept that hedge accounting is valid without evidence.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP S/4HANA Treasury and Risk Management, SAP Cash Management, SAP Bank Account Management, SAP Bank Communication Manager, or SAP Help Portal TRM documentation
+- `user-provided evidence` — authorization object exports, bank account master data reports, BAM configuration summaries, payment run logs, hedge documentation exports, financial instrument type summaries, in-house cash configuration notes, bank statement processing descriptions, or written descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such

package/skills/sap/sap-treasury-cash-risk-review/references/workflow-and-output.md

@@ -0,0 +1,89 @@
+# Workflow and output contract — SAP Treasury Cash Risk Review
+
+Use this reference for all treasury control finding classification, risk level assignment, remediation path selection, and output formatting.
+
+## Treasury control finding taxonomy
+
+| Domain | Finding class | Description |
+|--------|--------------|-------------|
+| `cash-position-liquidity` | `memo-record-uncontrolled` | Memo records (planned cash items) can be created or modified without authorization controls, distorting the cash position view and enabling fraudulent cash concentration decisions |
+| `cash-position-liquidity` | `bank-statement-processing-gap` | Electronic bank statement processing is not automated or is partially automated, creating a manual data entry risk and delaying cash position accuracy |
+| `cash-position-liquidity` | `liquidity-hierarchy-incomplete` | Liquidity item hierarchy does not cover all relevant cash flow sources (SD billing, MM invoice, payroll, intercompany), creating blind spots in the liquidity forecast |
+| `bank-account-management` | `bam-four-eyes-gap` | Bank account master data can be created or modified without a documented four-eyes (dual-control) approval workflow in SAP Bank Account Management |
+| `bank-account-management` | `unauthorized-signatory-change` | Bank account signatories can be added, modified, or removed without a separate authorization control distinct from the bank account maintenance role |
+| `bank-account-management` | `shadow-bank-account` | Bank account records exist in the system without a corresponding active BAM lifecycle governance entry — potential for untracked external payment destinations |
+| `in-house-cash-payment-factory` | `aggregation-single-approver` | Payment factory aggregation and external release can be authorized by a single approver without a second independent reviewer at the aggregation stage |
+| `in-house-cash-payment-factory` | `ihc-intercompany-posting-gap` | In-house cash intercompany postings can be created without a corresponding offsetting internal account entry — creates hidden intercompany imbalance in the in-house bank |
+| `in-house-cash-payment-factory` | `netting-authorization-gap` | Netting proposals can be created, modified, and settled by the same user without a separate settlement authorization control |
+| `financial-instruments` | `instrument-type-misconfiguration` | Financial instrument type configuration does not match the entity's stated hedging or investment strategy — creates a mismatch between TRM position reporting and actual risk exposure |
+| `financial-instruments` | `settlement-single-approver` | Financial instrument settlement can be authorized by the same user who created the transaction — no dual-control separation between deal entry and settlement release |
+| `hedge-exposure-management` | `hedge-documentation-incomplete` | Hedge designation documentation is missing required elements under IFRS 9 or IAS 39: risk component identification, hedging relationship description, effectiveness testing methodology, or hedge accounting start date |
+| `hedge-exposure-management` | `effectiveness-testing-gap` | Effectiveness testing is not configured or is not being run at required intervals — hedge relationship may not qualify for hedge accounting treatment |
+| `hedge-exposure-management` | `exposure-determination-mismatch` | Exposure determination source configuration does not match the actual source of the hedged exposure (e.g., FX exposure derived from SD orders but actual exposure is from intercompany loans) |
+| `payment-fraud-controls` | `single-user-payment-release` | A single user can create, approve, and release an external payment run without a second authorized approver — critical fraud control gap |
+| `payment-fraud-controls` | `bank-channel-security-gap` | Host-to-bank file transmission lacks integrity controls (digital signature, file hash verification, or SFTP with certificate authentication) — payment file could be intercepted or modified |
+| `payment-fraud-controls` | `payment-status-monitoring-gap` | No automated payment status monitoring or exception alerting is configured — rejected or returned payments may not be detected in time to prevent reuse of fraudulent payment instructions |
+| `treasury-sod` | `create-approve-release-combined` | User or role has combined authority to create financial instruments or payment requests, approve them, and release settlement or payment — full SoD bypass in treasury operations |
+| `treasury-sod` | `bam-payment-release-combined` | User or role has combined authority to manage bank account master data (TR_BANKI, TR_BANKA) and release external payments (F_PAYR_BUK, F_REGU_BUK) — enables unauthorized payment destination manipulation followed by payment release |
+| `treasury-sod` | `position-memo-record-combined` | User can modify cash position memo records and also release payment requests — enables manipulation of the cash position view to mask unauthorized outflows |
+
+## Risk level assignment
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Single-user external payment release authority (create + approve + release without dual-control); combined BAM write authority and payment release authority enabling payment destination fraud; unauthorized bank account creation path |
+| `high` | BAM four-eyes approval gap; hedge documentation deficiency creating derecognition or restatement risk under IFRS 9 or IAS 39; settlement dual-control gap in financial instrument processing; payment factory aggregation single-approver; unauthorized signatory modification; bank channel integrity control gap |
+| `medium` | Cash position accuracy gap from memo record governance weakness; liquidity hierarchy incomplete for material cash flow source; effectiveness testing configuration gap; netting authorization gap; payment status monitoring gap; exposure determination source mismatch |
+| `low` | Best practice deviation in instrument type design; minor liquidity hierarchy hierarchy gap for an immaterial cash flow category; reporting configuration deviation |
+
+## Remediation path decision tree
+
+For each finding:
+
+1. **Is this single-user external payment release authority (create + approve + release combined)?**
+   - Yes → `critical`. Immediately escalate to the treasury, audit, and GRC team. Do not authorize further external payments until dual-control is implemented and verified. Implement two-person payment release in SAP Bank Communication Manager and verify authorization object separation between payment creation (F_BKPF_BUK) and payment release (F_PAYR_BUK, F_REGU_BUK). State this explicitly.
+   - No → continue.
+
+2. **Is this combined BAM write authority and payment release authority (TR_BANKI/TR_BANKA + F_PAYR_BUK)?**
+   - Yes → `critical`. Escalate immediately. Separate bank account management authority from payment release authority at the role and authorization object level. This combination enables a user to create a fraudulent bank account and then release a payment to it.
+   - No → continue.
+
+3. **Is this a BAM four-eyes approval gap or unauthorized signatory modification?**
+   - Yes → `high`. Implement four-eyes approval workflow in SAP Bank Account Management for account creation, modification, and signatory changes. Assign separate approver roles distinct from the bank account maintenance role.
+   - No → continue.
+
+4. **Is this a hedge documentation deficiency or effectiveness testing gap?**
+   - Yes → `high`. Identify all active hedge relationships with incomplete documentation. Engage the treasury accounting team to complete IFRS 9 or IAS 39 hedge designation documentation. Configure effectiveness testing at the required intervals. Document the risk component identification, hedging relationship, and start date for each relationship. Flag for audit review.
+   - No → continue.
+
+5. **Is this a payment factory aggregation single-approver or financial instrument settlement dual-control gap?**
+   - Yes → `high`. Add a second, independent approval step at the aggregation or settlement stage. Verify that the second approver role is separate from the deal entry or payment request creation role.
+   - No → continue.
+
+6. **Is this a cash position accuracy or liquidity hierarchy gap?**
+   - Yes → `medium`. Map all material cash flow sources to the liquidity item hierarchy. Add memo record authorization controls. Automate bank statement processing where manual entry is currently used.
+   - No → classify as `low` and provide best practice guidance.
+
+## Workflow
+
+1. **Receive artifacts** — authorization object exports, bank account master data reports, BAM configuration summaries, payment run logs, in-house cash configuration notes, hedge documentation exports, financial instrument type summaries, bank statement processing descriptions, or written descriptions of the treasury landscape.
+2. **Classify each finding** by treasury control domain and finding class.
+3. **Assign risk level** per the table above (critical / high / medium / low).
+4. **Flag critical payment fraud findings immediately** — escalate before any other remediation discussion.
+5. **Apply remediation decision tree** per finding.
+6. **Prioritize** — critical payment fraud and BAM findings first; then high hedge documentation and instrument settlement gaps; then high payment factory and bank channel findings; then medium cash position and liquidity gaps; then low best-practice items.
+7. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Treasury control domain and finding class per finding
+2. Evidence label (documentation-based / user-provided evidence / inference)
+3. Risk level per finding (critical / high / medium / low)
+4. Finding detail: affected configuration object, transaction code or Fiori app, company code or treasury area, role or authorization object (if provided), and specific control gap
+5. Recommended remediation action (dual-control payment release implementation, BAM four-eyes approval workflow, hedge documentation completion, instrument settlement dual-control, payment factory second approver, bank channel integrity control, treasury SoD role separation, memo record authorization tightening, etc.)
+6. Treasury control posture after remediation
+7. Escalation notice for any critical payment fraud finding or combined BAM/payment-release authority — explicit statement that this requires treasury, audit, and GRC team sign-off before proceeding
+8. Prioritized remediation sequence
+9. Confirmation that no payments, trades, hedges, settlements, or bank account changes were initiated, approved, or released in this review