Technology

OpenQV: the authorization engine underneath the journey

OpenPaymentGPS shows customers where money is. OpenQV is the layer that decides whether an instruction submitted by an automated or intelligent system is permitted before value moves, and normalizes every bank and network event into one consistent language.

Before value moves

Twelve questions answered on every instruction

01
Who owns the automated system?
02
Who authorized the action?
03
What is it permitted to do?
04
Which account or payment method can it use?
05
What amount can it spend?
06
Which beneficiary can receive it?
07
Which payment rail should process it?
08
What compliance and risk controls apply?
09
Does the action require human approval?
10
What evidence must be preserved?
11
How is the transaction executed?
12
How is it reconciled?

Financial Action Gateway

A corporate treasury assistant, under policy

A $500 payment may proceed automatically. $5,000 asks for manager confirmation. $50,000 requires two authorized executives and enhanced beneficiary verification. A new or high-risk beneficiary pauses execution for compliance review.

Delegated authority

Grant for agent_2741

Treasury assistant acting for company_108. Adjust the instruction and watch the authorization decision change.

Action type

Amount$4,800

Beneficiary risk

auto_approve_below: $1,000
dual_exec_above: $25,000
ceiling: $50,000

POST /v1/financial-actions

{
  "agent_id": "agent_2741",
  "principal_id": "company_108",
  "action": "pay_invoice",
  "beneficiary": "merchant_742",
  "amount": 4800,
  "currency": "USD",
  "invoice_id": "INV-2026-817",
  "cross_border": false
}

200 OpenQV decision

{
  "decision": "APPROVED_WITH_CONDITIONS",
  "authorization_confidence": 99,
  "maximum_authorized_amount": 5100,
  "permitted_beneficiary": "merchant_742",
  "human_approval_required": true,
  "approvers_required": 1,
  "recommended_rail": "RTP_INSTANT",
  "evidence_record": "QV-347599",
  "valid_until": "1970-01-04T00:00:00Z"
}

Approved with conditions

confidence 99%rail RTP_INSTANTevidence QV-347599

Policy checks

Agent identity attestedagent_2741 bound to principal company_108
Action within delegated scopepay_invoice is a granted capability
Currency permittedUSD allowed
Amount within authority ceiling$4,800 of $50,000 ceiling
Beneficiary verificationmerchant_742 on the approved beneficiary list
Sanctions and AML screeningNo hits returned by the bank's existing AML system
Geographic and corridor policyDomestic corridor within permitted region

Execution conditions

Manager confirmation required before AI PayThrough executes
Single-use credential scoped to beneficiary, amount and expiry

The agent never receives account or card credentials. AI PayThrough executes a single-use instruction bound to merchant_742, capped at $5,100, expiring 1970-01-04T00:00:00Z.

Strongest differentiator

Verifiable Delegated Financial Authority™

The defensible position is proving that a specific system held permission for a specific economic action within defined limits, and being able to demonstrate it afterwards.

Invoice paymentsTreasury transfersSupplier paymentsCorporate procurementRecurring obligationsTravel purchasesInsurance paymentsProperty depositsMarketplace payoutsConversational bankingMachine-to-machine commerce

Machine-readable record, per transaction

Identity of the person or organization
Identity of the initiating system
Scope of its authority
Approved merchant or beneficiary
Maximum transaction amount
Permitted payment method
Geographic and time restrictions
Required approval level
Policy checks performed
Decision systems involved
Final payment instruction
Execution result and audit trail

Operating baseline

We observe, normalize and present. We never become the rail.

OpenPaymentGPS correlates payment status from authorized sources. It does not become SWIFT, Fedwire, CHIPS or any other settlement rail, and inferred status is never presented as confirmed settlement.

Traceability

Material decisions, state changes and privileged actions can be reconstructed after the fact.

Least privilege

A person, service or device holds only the authority its role requires.

Fact before estimate

Confirmed events are separated from estimates, predictions and user assertions.

Fail safely

Uncertainty and unavailable sources produce explicit exception states, never fabricated success.

Additive corrections

No one alters a historical source event; corrections are appended and auditable.

Observable operations

Metrics, logs, alerts and case queues carry named ownership of every failure.

Who it is built for

Bank operations teamsTreasury managersPayment investigatorsCustomer-service teamsCompliance personnelCorporate finance usersPlatform administrators

How performance is measured

Median exception-resolution time
Connector availability and event-ingestion latency
Trace completeness and reconciliation rate
Enterprise user adoption and active cases
Customer-service contacts per tracked payment
Pilot conversion to recurring contract

Overlay, not replacement

Keep your payment infrastructure. Add a controlled gateway on top of it.

Authorization, policy, credentials and settlement stay under the bank's control.

Bank-grade requirements

Private-cloud and on-premises deployment
Bank-controlled encryption keys
Regional data residency
Zero-data-retention options
No bank data used for model training
Configurable human approval
Role- and attribute-based permissions
Tamper-evident audit records
Model and provider governance
Explainable authorization decisions
Limits and beneficiary restrictions
ISO 20022-compatible messages
REST APIs, SDKs and webhooks
Integration with existing fraud and AML
PCI DSS-aligned credential handling
SOC 2 and ISO 27001 readiness
Operational resilience and failover
Emergency revocation