AKRU ships as one platform — 12 modules, 54 capabilities, five suites, one event fabric — but it deploys four different ways: full platform, modular, white-label, and API-first. The capabilities are the same in every model. What differs is who operates them, whose brand fronts them, and how they meet the systems you already run. Choosing well is less about features and more about answering three operating questions honestly: what do you want to stop doing, what must you keep, and whose name is on the experience?
Full platform: the operating system, end to end
The full deployment runs the entire lifecycle on AKRU — issuance, investor onboarding, the register, capital accounts, distributions, tax, reporting, and lifecycle events, with AKRU as SEC-registered transfer agent of record (registration effective July 4, 2026). This fits sponsors and managers whose current stack is the spreadsheet-plus-vendors assembly and who want the whole reconciliation problem to disappear at once. It is the fastest route to the platform's headline economics — $0.01 per-LP distribution processing, roughly 87% administrative-time reduction against a parallel legacy stack — because those numbers come from the single event fabric, and the full deployment puts everything on it. The honest cost: it is the largest operational change, and it deserves a gated implementation with formal reconciliation before cutover.
Modular: adopt the module that hurts most
The modular deployment takes the same platform one module at a time — the Tax Suite for a fund whose K-1 season is the bottleneck, the Investor Hub for a sponsor drowning in onboarding email, the register and transfer-agent function for a fund that needs recordkeeping to a regulated standard without touching anything else. Modules post to the same event fabric, so each addition compounds rather than fragments: adopt the register this year and the tax engine next, and the two share one source of truth from day one. This fits institutions with systems they are required or determined to keep, and teams that adopt infrastructure the way engineers do — smallest useful piece first, expand on evidence. It is also the natural entry point when procurement or board approval moves faster for a bounded scope than for a platform decision.
White-label: your brand, AKRU underneath
The white-label deployment puts your name on the experience — your portal, your paper, your client relationships — with AKRU operating the machinery underneath. Two groups choose it for opposite reasons. Financial institutions and wealth platforms use it to offer private-markets access under their own brand, on their own custody arrangements, without building administration infrastructure. Accounting and advisory firms and fund administrators use it to sell fund administration and tax operations as their own service line — the firm's client sees the firm; the platform does the work. The operating question is whether owning the client experience is strategic for you; if it is, white-label converts AKRU from a vendor into invisible plumbing.
API-first: the fabric without the interface
The API-first deployment is for institutions with their own front ends and engineering teams: the register, compliance checks, ledger events, and document flows are consumed as services, and AKRU's interfaces never appear. This is the model for platforms embedding tokenized-securities capability into an existing product, and for operations groups that want the event fabric as a system of record behind software they already own. It demands the most from the adopter — integration is real work — and repays it with the smallest change to what users see. The register still carries registrar-grade controls, the compliance checks still run before execution, and the audit trail still accumulates; the institution's own software simply becomes the window onto it.
How to decide in one meeting
Put four questions on a whiteboard. One: is the pain everywhere (full platform) or concentrated in one function (modular)? Two: must the client experience carry your brand (white-label) or is AKRU's fine? Three: do you have engineering capacity that wants control (API-first) or an operations team that wants outcomes? Four: what does your regulator or auditor need to see unchanged? Most institutions land on an answer inside the hour, and the choice is not a permanent commitment — because every model runs on the same fabric, moving between them is a configuration change, not a migration. Start modular, go full when the evidence is in; start white-label, add API surface as your product grows. The deployment model is how you meet the platform, not how you marry it.
Frequently asked questions
Can we switch deployment models later?
Yes. All four models run the same 12 modules on the same event fabric, so moving from modular to full platform, or adding API access to a white-label deployment, is a configuration and contract change — not a data migration.
Is the transfer agent included in every model?
The registered transfer-agent function is available in every model and is the default in full-platform deployments. Modular adopters can take the register and TA function alone; white-label and API-first deployments include it where the register lives on AKRU.
Which model is fastest to go live?
A single-module adoption is typically fastest, since scope is narrow and reconciliation is limited to one function. Full-platform implementations run as gated projects with formal reconciliation before cutover — slower by design, because launch clearance is earned, not assumed.
Related reading
The tokenized fund stack vs the traditional admin stack
Registrar change: how funds migrate recordkeeping without interruption