AION Nexus CRM walkthrough
A regulated client, from first contact to activated
Eight screens following one customer through the CRM: a scored lead, an onboarding case routed to compliance, identity verification, a screening match that needs a written justification, and a risk rating nobody can change silently. Every control you see is enforced in code.
Every screenshot on this page shows demonstration data in a tenant created for the purpose. AION Nexus is pre-GA and has no customers yet.
Step 1: A lead arrives
Scored, and the score explains itself
Every lead carries a score, a band and the reasoning that produced it. The engine is a weighted rule set over recency, source quality, fit against your ideal customer profile and engagement. It does not learn its weights from your data, so a supervisor can reproduce any score in the list.
- Bands as well as raw numbers, so a queue can be worked by priority.
- Re-runs when an input changes, so a score is never stale.
- The same inputs always produce the same score, on any day, for any reviewer.
Step 2: The book of business
Every account, owned by someone
Customers carry an owner, a status and an industry, and the record is the spine everything else hangs from. Deals, activities, documents, onboarding cases, verifications and risk ratings all resolve back to it.
- One customer record, shared across every department.
- Account hierarchies for group structures and their subsidiaries.
- Territory and ownership drive who sees what, through the permission model.
Step 3: Onboarding
A case with a lifecycle you can follow
Onboarding is a first-class object with its own states: initiated, routed to compliance, in review, approved, activated, abandoned. Each transition is recorded, and the handoff to a relationship manager is a field on the case.
- Beneficial-ownership and entity-structure capture built into the file.
- Routing to compliance is a state the case is in, which the system enforces.
- Abandoned applications stay on the record with the reason attached.
Step 4: Identity verification
Adjudicated by a person, recorded by the system
Verifications move through a status progression an auditor can follow, and an adjudication records who decided, when, and on what basis. The documents themselves are encrypted at the field level with versioned keys.
- Approve, reject or request more documents, each an auditable event.
- Verification has an expiry, so periodic refresh arrives as a queue.
Until you supply vendor credentials, identity verification falls back to a demonstration scorer that returns a randomized risk value. The screenshot shows that demonstration mode. The monitoring rules themselves contain no randomness.
Step 5: Screening
A possible match, and the justification required to clear it
Sanctions, politically-exposed-person and adverse-media screening produce matches that a human has to dispose of. Suppressing one requires a written justification, and the system records who wrote it. Examiners sample exactly this when they review your false positives.
- Justification is enforced at the server, so the interface cannot skip it.
- Match score, matched name and list are all retained against the decision.
- Screening is available to a CRM-only tenant. It is not gated behind the financial module.
Step 6: Risk rating
Nobody moves a rating silently
Ratings carry the factors that produced them, the methodology version in force at the time, and a mandatory justification on any override. The previous rating is not overwritten. It stops being current, which means the history of how a customer came to be rated the way they are survives.
- Jurisdiction, product and channel, customer type and transaction profile, each weighted.
- An officer override requires a written reason before it will save.
- Rating changes appear in the audit trail like any other action.
Step 7: Investigation
Cases that close properly
Anti-money-laundering, fraud, enhanced due diligence, sanctions and quality-assurance reviews share one case lifecycle, with linked evidence and a disposition that has to be written down. A case is the unit an examiner will ask to see end to end.
- Evidence links back to the records it came from.
- Disposition and rationale are captured on close, in their own fields.
Step 8: What is not here
A CRM-only tenant has no money-movement surface
Look at the navigation. There is no treasury, no payments, no currency dealing. For this tenant those endpoints are refused at the request layer and return HTTP 403. That gives your security team a smaller thing to assess: a CRM, and only a CRM.
- The check sits in front of the route handlers, so anything added later is closed by default.
- This tenant was created without the financial module in the first place.
- Identity-verification and anti-money-laundering endpoints sit outside that gate, under the compliance permission domain.
