AION Nexus Financial Operations walkthrough
One payment, and every control it has to pass
Nine screens following a single instruction from draft to settled: screening before authorization, an authorization the person who raised it cannot give, two distinct approvers, reconciliation against a bank statement, and an audit record that detects its own tampering.
Demonstration data throughout, in a tenant created for the purpose. This layer is implemented against real vendor contracts and has not yet run against live rails. Nothing on this page has moved real money.
Step 1: Turning it on
Switched on per tenant, at the endpoint
Financial operations is a module a tenant either has or does not. Enabling it opens the corresponding endpoints; disabling it closes them at the request layer, so the navigation and the API always agree. Membership is read from the signed session, so a change takes effect at next sign-in.
- The CRM core is always on and cannot be switched off.
- A tenant without this module returns HTTP 403 on every money-movement route.
- Enabling it later takes a configuration change.
Step 2: The instruction
Draft, screened, awaiting authorization, authorized, transmitted, settled
A payment instruction is a state machine, and every transition is guarded. The queue in this screenshot holds instructions at five different points in that lifecycle at once, the ordinary state of an operations desk on any given morning.
- Beneficiary and sanctions screening runs before authorization is possible.
- A screening hit blocks the instruction outright.
- Compliance can place a pre-execution hold on anything in the queue.
Step 3: The refusal
The person who raised it cannot approve it
The dealer who created and submitted this instruction attempts to authorize it, and is refused with an HTTP 403. The authorization permission belongs to a different role from the one that raises instructions. Separation of duties lives in the permission model, where the system can enforce it.
- Self-approval is rejected unconditionally, at any amount.
- Completing the authorization requires two distinct approvers, neither of them the maker.
- Automated and assistant-driven actors may prepare a payment. They can never authorize one.
- The rule is enforced in the money-movement guard, ahead of the route handler.
Step 4: Dealing
Currency dealing and the order book
Limit and stop orders, liquidity-provider routing and fill reconciliation. The platform instructs your providers and never holds your funds, under the same control model the payment path uses.
- The default provider is hard-coded as unavailable, so an unconfigured deployment cannot deal.
- Vendor credentials live in a bring-your-own-key vault and are revocable by you.
Implemented in full against real provider contracts, and never executed against a live liquidity provider. The maturity matrix on the Financial Operations page marks each capability individually.
Step 5: Treasury
Knowing where the cash is, in every currency
Balances are derived from the ledger and split into settled, spot-pending and forward-pending. Forward positions count toward your available balance only once their value date arrives, which keeps the forecast honest.
- Per-currency positions across the accounts you hold with your own providers.
- Cash-flow forecasting and liquidity monitoring built on the same source.
This is forecasting and monitoring. A materialized position book, mark-to-market valuation and margin management are on the roadmap.
Step 6: Reconciliation
A break that ages in public
A camt.053 statement is imported and matched against instructions. Five entries reconcile; one does not, and it stays visible with its age attached. Re-importing the same statement is idempotent, so a repeated file cannot double-count.
- Unmatched entries become breaks with a category, a status and an owner.
- Aging is the point: a break detected today tells you nothing a nine-day-old one does not.
- Safeguarding evidence is produced from the same reconciliation, for the client-money case.
Step 7: Safeguarding
Evidence for the client-money reconciliation
Where client funds are involved, the reconciliation has to be evidenced. This produces that evidence from the ledger on demand, gated by the compliance permission domain.
- The platform never holds client funds. Money moves between your accounts and your counterparties.
- Producing evidence is itself a permissioned action and appears in the audit trail.
Step 8: The audit trail
Records that detect their own tampering
Audit records are hash-chained per tenant, so an edit or a deletion breaks the chain and shows up. Updates record which fields changed and never the values, so the audit log never becomes a second copy of your customer data.
- High-severity events are written to an append-only tier.
- Exportable, because an auditor will want it outside the system as well as in it.
- Every step earlier on this page appears here as an event.
Step 9: Who can do what
Segregation of duties as a first-class feature
Nineteen permission domains with seeded roles including Compliance Officer, Auditor, Risk Analyst, Treasury Manager and CFO. Role changes are themselves subject to maker-checker, so an administrator cannot quietly grant themselves a capability.
- The refusal in step three is this model doing its job.
- An external auditor can be given a scoped, read-only identity.
