fintech-engineer
ReviewAudited by ClawScan on May 10, 2026.
Overview
This is an instruction-only fintech assistant, but it includes unqualified claims about financial certification, uptime, accuracy, and audit success that users should verify before trusting.
Review this skill carefully before using it on real financial systems. It has no code or install-time behavior, but its domain involves payments, banking, trading, wallets, and regulated data. Treat any compliance, certification, audit, uptime, or accuracy claim as unverified unless the agent provides independent evidence.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A user could be led to believe a financial system is certified, production-ready, or regulator-approved when those claims have not been independently verified.
This is a canned completion statement that could lead the agent to claim audited compliance, certification, performance, and transaction accuracy without artifact-backed proof.
Delivery notification: "Fintech system completed. Deployed payment processing platform handling 10k TPS with 100% accuracy and 99.995% uptime. Achieved PCI DSS Level 1 certification ... passed regulatory audit with zero findings."
Require the agent to report only verified results and attach evidence for certifications, audits, uptime, and accuracy claims; do not accept compliance claims without documentation.
If connected to real systems, mistakes could affect payments, refunds, chargebacks, or settlements.
These are high-impact payment workflows where incorrect implementation or unsafe tool use could move money, alter balances, or affect customer transactions, though they are aligned with the fintech purpose.
Payment processing systems: - Gateway integration - Transaction routing - Authorization flows - Settlement processing - Chargeback handling - Refund processing
Use explicit user approval for any money-moving action, test in sandboxes, require code review, and separate design guidance from production execution.
Over-broad credentials could expose financial accounts or enable unauthorized payments, trades, or data access.
Wallet, exchange, banking, and open-banking integrations commonly require sensitive account credentials or delegated permissions, even though no credentials are hardcoded or required by the install metadata.
Blockchain integration: - Cryptocurrency support - Smart contracts - Wallet integration - Exchange connectivity ... Open banking APIs: - Account aggregation - Payment initiation - Data sharing - Consent management
Use least-privilege, revocable credentials; avoid sharing seed phrases or private keys; prefer sandbox accounts; and confirm every permission scope before use.
Incorrect or sensitive stored context could lead to flawed compliance assumptions or accidental exposure of financial project details.
The skill may rely on retrieved context for financial and compliance requirements; if that context is stale, poisoned, or contains secrets, it could affect downstream design decisions.
When invoked: 1. Query context manager for financial system requirements and compliance needs
Verify retrieved requirements against current authoritative sources and avoid storing secrets, credentials, or regulated personal data in shared context.