Atlas. The graph your CRM is not.

A CRM stores rows. Atlas holds your brokerage as one connected graph, with every client joined to every trade, deposit, ticket, document, partner and provider that touches it, then remembers what happened and learns from what you decided.

Atlas is ours. We built it over years of research into how brokerages actually work, because nothing off the shelf models a broker: not a CRM, not a data warehouse, not a general purpose graph. The entities, the relationships and the rules in it are specific to this industry and to no other.

Clients31,482Trades4.1MDeposits188,204Tickets62,110Partners412Providers17Documents29,806Instruments182AtlasRead
  1. ReadAtlasEvery source system, continuously
  2. JoinAtlasInto one graph, per entity
  3. NoticeAtlasWhat moved, and what it is worth
  4. DecideAgentInside your limits, or it asks
  5. ActAgentIn the system that owns the record
  6. RecordAtlasThe outcome, where every agent reads it

Per entity · per licence · never across your entities

Five things it does that a database does not.

01

One connected graph

A client is not a row. It is a node joined to every trade, deposit, ticket, document and partner that touches it, so a question crosses systems without anyone building a report.

Answer timeUnder 2s
02

Memory

Atlas remembers what happened and what was decided, because every agent writes its outcome back. When the same pattern returns, the agent that picks it up opens with what you did last time and what it was worth.

Decisions retainedEvery one
03

Context

It knows which entity, which licence, which regulator and which signed agreement applies before it drafts anything. The same event in two entities gets two different answers.

Entities held apartAll
04

Feedback loops

Approve, modify or reject, each one is signal. It lands in Atlas rather than in the agent that asked, so modifying one draft moves every agent that reads the same record.

Approved as drafted98%
05

Learning, two ways

Individually, per account, so a client who always funds on a Thursday is not chased on a Monday. And in cohorts, so what works on one segment is applied to the segment, not guessed at one client at a time.

Applies toAccount and cohort

Ask it in plain words. Get the rows behind the answer.

Because the records are joined, a question crosses payments, trading, support and finance without anyone building a report for it.

Why did deposits fall yesterday?Under 2s
Which clients are about to leave, and what are they worth?Under 2s
What does this introducer actually cost us after rebates?Under 2s
Which provider fills worst on gold, and by how much?Under 2s

Atlas knows. The agents act.

These are two different things and the difference matters. Atlas is the only part that touches your systems, and it only ever reads them. An agent is the only part that does anything, and everything it knows it read from Atlas first.

Atlas

The graph. It knows.
  • Connects to the trading platform, payment providers, ticketing and the ledger, read only
  • Joins those records into one graph, held separately per entity
  • Keeps the memory: what happened, what was decided, what it was worth
  • Holds the context: which entity, which licence, which signed agreement applies
  • Learns from every outcome, per account and across cohorts in your own book

What it never doesAtlas never acts. It holds no write credentials on any of your systems and cannot send, pay, credit, close or message anything.

The eight agents

The operators. They act.
  • Read what they need from Atlas, scoped and logged on every read
  • Decide, inside the autonomy level and the amount you set per function
  • Act in the system that owns the record, or prepare it and ask a named person
  • Write the outcome back into Atlas, where every other agent can read it
  • Carry the evidence: what they saw when they acted, attached to the action

What it never doesAn agent holds no data of its own. Everything it knows it read from Atlas, and everything it does it writes back, which is why no agent has a private view of your book.

One turn of the loop, and who owns each step.

The sixth step is the one that compounds. An outcome goes back into the graph, not into the agent that produced it, so the next agent to touch that client starts from what already happened rather than from nothing.

  1. 01AtlasReadEvery source system, continuously
  2. 02AtlasJoinInto one graph, per entity
  3. 03AtlasNoticeWhat moved, and what it is worth
  4. 04AgentDecideInside your limits, or it asks
  5. 05AgentActIn the system that owns the record
  6. 06AtlasRecordThe outcome, where every agent reads it

It learns from you, and it stays yours.

01

Per account

A client who funds on Thursdays is not chased on Mondays. A client who only ever replies in Portuguese is never written to in English.

02

Per cohort

What works on one segment of your book is applied to that segment, rather than rediscovered one client at a time. Cohorts are built from your own accounts.

03

Inside your walls

Your graph is yours. Entities stay separated from each other, your data stays in your region, and what Atlas learns on your book stays on your book.

Cross-entity accessNone

See your own graph inside three weeks.

Day one we take read access. Over the first week Atlas joins your records and we reconcile them against your own reporting. In week two you get the first list.