Skip to content
Superior CRM

Platform

The parts you only notice when they fail

Nobody chooses a CRM for its tenancy model or its audit chain, and everybody who has been burned once asks about them first. This is that page: what is enforced, how, and what is not.

Tenancy

One deployment, and no way to see somebody else’s office

Multi-tenant is easy to claim and hard to guarantee. The guarantee here is structural: not that every query filters correctly today, but that a query cannot fail to filter tomorrow.

The filter is not the code’s to forget
Every query is narrowed to the signed-in organisation by the database client itself, before any application code sees it. A feature written next year is tenant-safe by default rather than by review.
New tables cannot be missed
The tables it applies to are discovered from the schema rather than kept in a list somebody maintains. A list is a thing that goes stale silently; discovery is not.
Reps are narrowed further, on the data
An admin sees the office, a sales rep sees the merchants and leads assigned to them. That narrowing happens to the rows, not by hiding buttons on a screen that would still return the data if asked directly.
The merchant portal is a fourth wall
The one role held by somebody outside your business is refused on every route not explicitly marked merchant-facing, before permissions are consulted at all. A portal login is bound to exactly one merchant, and an unbound one resolves to nothing rather than to everything.

Arithmetic

Money that survives being checked

Residuals decide what people are paid, so the maths is the product rather than a detail of it.

Integers, in the currency’s own minor unit
No amount is ever a floating-point number. The exponent for the currency is applied explicitly, and rounding happens once, at a stated point, rather than accumulating through a chain of divisions.
No stored balance
What a partner can draw is derived from the ledger every time it is asked — allocations less payouts still in flight. There is nothing to fall out of step, and nothing to reconcile by hand at quarter end.
Holds that release correctly
A pending payout reserves its amount. A failed, returned or voided one gives it back. That distinction is a pure function with its own tests, because it is the one that decides whether somebody is paid twice.
A missing FX rate stops the run
Rates are directional and effective-dated, a manually entered rate outranks a fetched one on the same day, and no rate is ever quietly inverted to fill a gap. A run that cannot be computed correctly does not complete approximately.

Evidence

A record somebody else can verify

An audit trail that the administrator can edit is a record of what they were willing to leave in it.

Activity is hash-chained
Audit rows are sealed hourly into checkpoints, each linked to the one before it. Changing a row after the fact breaks the chain from that point onward, which the verifier reports.
And anchored off the box
The head of those chains is signed nightly and sent somewhere this deployment cannot reach. That is the difference between an edit being detectable and an edit being detectable by somebody other than whoever made it.
Personal data is registered, not remembered
Every table holding personal data is accounted for in the export and erasure registry, and a build guard fails when a new one is not. A subject-access export that quietly goes stale is the failure this prevents.
Keys can actually be retired
Stored provider credentials, 2FA secrets and contact numbers are encrypted under a keyring rather than one key, so a rotation is possible: a sweep moves values across and reports, from the rows themselves, when the old key is safe to drop.

Operations

When something stops, somebody is told

The failure that costs you a portfolio is not a crash. It is an import that quietly stopped running six weeks ago.

Every scheduled job reports itself
Last run, what it returned, consecutive failures, whether it is overdue. Silence from a job that should be chatty is treated as a failure, and jobs that are legitimately quiet are marked so a daily false alarm does not train everyone to ignore the page.
Nothing leaves the building without a queue behind it
Every email and text is enqueued with a key naming the occurrence, delivered with retries and shared backoff, and dead-lettered rather than dropped. A message that failed is a row you can find, not an absence you infer.
Something reads all of it
A watcher evaluates that report every five minutes and sends to a webhook or an address, deduplicated, with an all-clear when a condition clears. It deliberately does not use the queue — a monitoring path must not depend on the thing it monitors.
Off is a decision, and it says so
Alert destinations are unset until you set one, and the endpoint reports “not configured” in words rather than reporting healthy. A monitor that looks green because nothing is watching is the worst of the available states.

Scope

This system holds no cardholder data, and is not built to

It carries merchant records, contact details, documents and residual arithmetic. Card numbers live in the payment systems that are assessed for them — and keeping that boundary is the reason a CRM breach here is a serious problem rather than a catastrophic one.

It does not move money either

Payout runs are computed, assembled and approved here, then handed to a disbursement seam. The CRM never holds funds and never initiates a transfer on its own — which is what keeps an approval a real control rather than a formality.

Your own database

Its own frontend, API and database, independent of any gateway. A processor connector is an optional outbound integration, never a dependency — including the connector to NMI. What that buys you is the ability to change processors without changing CRM.

Limits

What it does not do yet

Stated here rather than discovered in week three. If one of these is central to what you are buying, say so early and we will tell you honestly whether to wait.

Processor connectors are unverified
Six adapters exist and none has been run against its processor’s sandbox. The product refuses to enable an unverified adapter in live mode, and a test keeps them that way until somebody has actually run one.
No KYC, KYB, MATCH or credit data
Underwriting is a structured human workflow with stipulations, documents and decision rules. There is no automated identity or credit decisioning behind it.
Erasure does not reach document bytes
Export and erasure cover the database. Files in blob storage are not yet deleted by the same job, which is a known gap rather than a discovered one.
The national DNC registry is not checked
Internal do-not-call state, consent and quiet hours are enforced. The federal registry needs a subscription and is not wired in — and the seam records unknown rather than clear, so it cannot be mistaken for a check that ran.

How that compares with NMI Merchant Central →

Send us your security questionnaire

We will fill it in properly, including the questions where the answer is no. That is usually faster than a call.