AION Nexus Financial Operations
Deal, pay, settle and reconcile in the same system
Currency dealing, payment instructions, settlement, reconciliation and a compliance engine, sharing the CRM's data model, permissions and audit trail. It is entirely optional, and nothing here is needed to run the CRM.
This layer is implemented against real vendor contracts and has not yet run against live rails. The matrix below gives each capability its own status.
Control model
The money-movement control model
Five invariants that fail closed. Every route that can move money passes through the same guard, and a test in continuous integration fails the build if a money route is added that does not call it. The build enforces it, so it holds by construction.
-
No custody
The platform never holds client funds. It instructs your providers; money moves between your accounts and your counterparties, never through us.
-
Authorization integrity
Every execution requires a bound authorization record whose tenant and instruction must match, protected by a SHA-256 integrity check. An altered authorization is refused.
-
Credential validity
The default provider is hard-coded as unavailable, so an unconfigured deployment cannot move money at all. Revoking a credential immediately severs the ability to execute against that provider.
-
Dual control
Self-approval is rejected unconditionally, at any amount, whoever you are. A second authorizer is required above a threshold that defaults to CAD/GBP 10,000, and the strict interpretation applies unless a tenant explicitly opts out.
-
Human authorization
Automated and assistant-driven actors may prepare a payment. They can never authorize one, and the guard enforces that on every request.
Dealing and payments
Trade, instruct, settle
The dealing and payment lifecycle, with maker-checker applied at the points where a mistake is expensive.
- Currency dealing with a swap and hedge lifecycle under maker-checker.
- An order book supporting limit and stop orders, liquidity-provider routing and fill reconciliation.
- Payment instructions and batches, with screening blocks and control-total validation before release.
- Settlement instructions on a T+2 cycle using a business-day calendar.
The holiday calendar is provisional pending compliance sign-off. Until that is finalized, treat settlement dates near a public holiday as needing confirmation.
Reconciliation and messaging
Reconcile against the bank's own message formats
Statement and payment messaging parsed and generated natively, so reconciliation is not a manual export-and-match exercise.
- ISO 20022 camt.053 and camt.054 statement ingestion, and pacs.008 and pain.001 payment messages.
- A two-pass matcher: first on end-to-end reference, then on amount within a date window.
- Unmatched items age into breaks and escalate to a named owner.
- SWIFT MT103, MT202, MT900 and MT910 construction and parsing with field-format validation.
Compliance engine
Screening, cases and regulatory reporting
Rule-driven throughout, so a compliance officer can say exactly why an alert fired.
- Identity verification and enhanced due diligence, with ultimate-beneficial-owner mapping.
- Anti-money-laundering monitoring on velocity, daily-total and geographic rules resolved per tenant.
- Sanctions and adverse-media screening with case management and evidence capture.
- Suspicious-activity report drafting that requires a compliance officer to sign off before submission.
- Travel-rule data capture for qualifying transfers.
Until vendor credentials are configured, identity verification falls back to a demonstration scorer that returns a randomized risk value. The monitoring rules themselves contain no randomness.
Treasury
See where your cash is going, in every currency
Forecasting and liquidity monitoring across your accounts and currencies.
- Cash-flow forecasting from scheduled settlements and known obligations.
- Liquidity monitoring with configurable thresholds and alerting.
- A dual-control approval queue for outbound instructions.
This is forecasting and monitoring. It is not a position book, and there is no mark-to-market valuation or margin management. See the maturity matrix.
Maturity
Where each capability stands
The distinction that matters is between code that has run against a live counterparty and code that has not. The status column says which is which, capability by capability.
| Capability | Status | Detail |
|---|---|---|
| Money-movement control model | Live | Enforced and covered by tests, including a build-failing check that money routes call the guard. |
| Per-tenant module gating | Live | Financial endpoints return HTTP 403 at the request layer when the module is disabled. |
| Compliance rule engine | Live | Rules resolve per tenant and are deterministic. Vendor screening itself awaits credentials. |
| Currency dealing and order book | Built, awaiting live rails | Implemented in full; never executed against a live liquidity provider. |
| Payment instructions, batches and settlement | Built, awaiting live rails | Implemented against real provider contracts; never run against production rails. |
| ISO 20022 and SWIFT messaging | Built, awaiting live rails | Parsing and generation are covered by tests against sample messages. |
| Vendor rails | Built, awaiting live rails | Every provider integration ships disabled until you supply credentials. |
| Settlement business-day calendar | Partial | Working, but the holiday table is provisional pending compliance sign-off. |
| General ledger | Partial | A purpose-built ledger is the source of truth. A third-party ledger integration exists behind a disabled flag. |
| Settlement netting | Planned | Planned. Instructions settle individually today; netting is a design-partner item. |
| Mark-to-market and margin calls | Planned | Planned. Treasury covers forecasting and monitoring; valuation and margin are the next layer. |
| Materialized position book | Planned | Planned. Positions are derived on read today; maintaining them as a materialized book is the next step. |
Activation
How it turns on
Three steps, each reversible, and none of them required to keep using the CRM.
- Enable the module for your tenant. Until you do, the financial endpoints are refused at the request layer.
- Configure your dual-control threshold and your approver roles. The strict default applies until you change it.
- Provision vendor credentials into the bring-your-own-key vault. Nothing can reach a provider before this step.
