Skip to main content
This page describes how QWED Finance is organised inside.

​
Where it runs

QWED Finance is a library. It runs inside your process and makes no network calls. Your code calls a guard with the model’s output, and decides what to do with the result: act on it, hold it, or send it to a person.

​
Guard architecture

​
Component diagram

​
Verification flow

Every check follows the same path. Input that cannot be parsed, or that a check detects as ambiguous, fails closed: it is rejected, never passed through as if it were correct. Not every ambiguity is detected: cash flows that change sign more than once can have several IRRs ([-100, 230, -132] has roots at 10% and 20%), and verify_irr checks the claim against the first real root it finds instead of rejecting the input. Most guards return a rejected result; some methods raise instead (for example verify_irr raises ValueError for a claim that is not a number), so treat an exception from a guard as a rejection too. CrossGuard, UCPIntegration and the built-in OpenResponsesIntegration tools also issue receipts. UCPIntegration can return PENDING_REVIEW when an amount needs an AML flag.

​
Data flow

​
Verification receipt

Receipts are unsigned until you call get_signature(key). See Compliance and auditing.

​
Cross-guard pipeline: SWIFT with sanctions

CrossGuard.verify_swift_with_sanctions() runs three steps. An empty or missing sanctions list fails closed as unscreened. A name the screening cannot assess is sent to review, never cleared.

​
Class diagram

​
Deployment

  • Python: install qwed-finance and call the guards from your service.
  • Node.js: @qwed-ai/finance runs the Python package in a child process and passes JSON over stdin; install qwed-finance on the same machine. See the Quickstart.
  • Receipts and audit logs: AuditLog keeps receipts in memory. export_json() returns all of them as one JSON array, which suits reporting. To check receipts later, export each one with to_json() beside its signature, one pair per receipt, as shown in Compliance and auditing.

​
Design principles

​
1. Determinism first

The same input gives the same verdict. No sampling, no confidence scores.

​
2. Solvers and high precision over probability

Use solvers (Z3, SymPy) and high-precision arithmetic (mpmath, Decimal) instead of probabilistic confidence scores. The numerical checks run at a fixed, finite precision (30 decimal places for DerivativesGuard, 50 digits for BondGuard) and accept claims within a stated tolerance: they are repeatable, not exact symbolic answers. The IRR fallback reports verification_mode="HEURISTIC".

​
3. Audit where it matters

CrossGuard, UCPIntegration and the built-in OpenResponsesIntegration tools generate receipts automatically. Direct guard calls and custom Open Responses tools return result objects; create a receipt with ReceiptGenerator when you need an audit record.

​
4. Fail closed

Input that is malformed, ambiguous or missing is rejected, never treated as passing.