MCP server providing financial compliance and risk assessment tools for banking and payment processing, including ISO 20022 validation, risk scoring, PII redaction, and policy checking.
Regulus provides 5 tools with complete JSON schemas and descriptions. Naming follows verb_noun convention (get_*, make_*, iso20022_*, risk_*). Descriptions are present and contextual (avg ~120 chars), meeting baseline minimums. However, parameter descriptions lack depth, many omit format constraints, ranges, or validation rules. Output schemas are not documented. Error handling is minimal; no recovery guidance or actionable error messages visible in source. Security considerations for financial tools (payment, risk scoring) are not evident in tool definitions. Composition is reasonable: tools are single-purpose, but chaining requirements (e.g., get_account_balance → make_payment) are not documented.
Get the current balance of a bank account. Use this when the user asks about their balance or account status.
Get recent transactions for a bank account. Use this when the user asks about their transaction history or recent activity.
Validates ISO 20022 payment messages for compliance with the standard. Supports pain.001 (credit transfer initiation), pain.002 (payment status), pacs.008 (FI credit transfer), pacs.002 (FI status), and camt.053 (bank statement).
Initiate a payment from one account to another. Use this when the user wants to transfer money or pay someone.
Calculates risk score for financial transactions. Analyzes amount, currency, counterparty, geography, and patterns to produce a risk assessment with score (0-100) and risk level.
Output schemas not documented. LLMs cannot plan downstream calls or extract structured data from responses. Baseline: 100% of A+ tools document return types.
Parameter descriptions lack format constraints and validation rules. E.g., 'amount' in make_payment has no range, precision, or currency validation guidance. Baseline: descriptions should state format, range, and allowed values.
No error handling or recovery guidance visible. Financial tools (make_payment, risk_score) should document failure modes and next steps. E.g., 'Insufficient funds, check balance with get_account_balance' or 'High risk score, escalate to compliance team'.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2025-06-18+ | v2 |
make_payment lacks confirmation/dry-run pattern for irreversible operations. Agents should be able to preview payment before execution to prevent accidental transfers.
get_transactions lacks pagination parameters (limit, offset, cursor). Large transaction histories will blow context windows. Baseline: tools returning lists must support pagination.