Loading…
Open-Policy Exchange
~8 min to deploy
SAP Vendor Payment Release Gate
Holds a vendor payment run until the bank details, sanctions evidence, and dual approval all check out.
For: Finance and AP teams releasing payments from SAP S/4HANA
SOC 2 CC8.1ISO 27001 A.5.19SOX payment controls
What it enforces
Bank-detail change hold
Blocks a payment when the vendor's banking details changed since the invoice was raised.
Sanctions freshness
Requires fresh sanctions evidence before an international payout executes.
Treasury dual approval
Requires dual approval before corporate funds move above the threshold.
sap-vendor-payment-release-gate.yaml
# SAP Vendor Payment Release Gate
# Fork: this is the fintech pack's Cross-Border Sanction Check + Treasury Lock
# expressed at the SAP payment-run boundary.
apiVersion: decionis.dev/v1
kind: PolicyPack
metadata:
name: sap-vendor-payment-release-gate
surface: sap
workflow_key: vendor_payment_release
standards: [SOC2-CC8.1, ISO27001-A.5.19]
defaults:
mode: shadow
emit_dossier: true
rules:
- name: bank_detail_change_hold
when: "action == 'payment.release'"
decision: |
BLOCK IF vendor.bank_details_changed_since_invoice == true
ALLOW OTHERWISE
reason_code: bank_details_changed_after_invoice
- name: sanctions_freshness
when: "action == 'payment.release' AND cross_border == true"
decision: |
BLOCK IF sanctions_evidence.age_hours > 24
ESCALATE IF sanctions_evidence == null
ALLOW OTHERWISE
reason_code: stale_sanctions_evidence
- name: treasury_dual_approval
when: "action == 'payment.release'"
decision: |
ESCALATE IF amount_usd >= 10000 AND approvals.count < 2
BLOCK IF amount_usd >= 250000 AND approvals.count < 2
ALLOW OTHERWISE
reason_code: dual_approval_required
Fork it, change the thresholds to match your environment, and deploy in shadow mode first — it defaults to listen-only so nothing in your live pipeline changes.
How to install it
Follow the install path for this surface, then paste the forked YAML as your policy config.
What to do next
This recipe is one step in a path. The same five steps apply to every recipe in the exchange.
- Simulate this recipe
Run the policy against a realistic action in the browser. Push it past what the rules allow and watch the verdict come back. No account.
- View the signed Decision Dossier
See exactly what was decided and why: the rule that fired, the evidence it read, the policy version in force, and an Ed25519 signature you can verify yourself.
- Deploy in shadow mode
Measure what the policy would have caught on your own traffic without touching the live path. Every recipe defaults to shadow, so the first deployment carries no execution risk.
- Connect a real workflow
Point the same policy at the system where the action actually originates — a checkout, an ERP posting, a Zap, an agent's tool call.
- Share the verified result
Publish the proof: a public verification link, an embeddable badge, a PR comment, or an anonymized shadow-mode finding. This is how the next person discovers Decionis.