Trust · Security
In a financial system, the worst security failure is not only exposed data. It is an economic effect nobody was authorised to cause. Orangepill is designed so that controls apply at the execution layer, before an operation can change financial state.
Principle
A valid API call can still be a bad financial action: the wrong tenant's wallet, a route that should not be used, an amount outside policy. Checks that only answer "is this caller authenticated?" miss those cases. In Orangepill, operations are validated and authorised through controlled lifecycle transitions before they affect financial state.
Control areas
Each tenant operates in an isolated execution context. Financial state, ledger records, permissions and workflow execution are scoped to that tenant. The design intent is that one tenant's operations never touch another's balances.
Authorization is evaluated per financial operation, not only per session. Provider authorization and controlled settlement steps sit inside the execution lifecycle rather than in the calling application.
Policy is checked before execution: transaction limits, allowed provider routes, wallet balance constraints and allocation rules. Software agents receive permission-scoped, policy-bound access rather than general access to financial operations.
Provider credentials are stored server-side in provider configuration. Callers, including agents, use Orangepill credentials and do not need to hold provider credentials themselves.
Encryption and infrastructure controls
Authentication methods, encryption, key and secrets management, hosting and operational controls are where marketing summaries tend to overstate. We cover them directly with your security team during a technical evaluation, describing what is in place today and what is not.
This page does not claim SOC 2, ISO 27001 or any other certification. How we approach trust claims →
We will walk your team through isolation, authorization and policy controls, and answer the questions this page does not.