UNIFINplatform

Solution

Unifin Architect Builder

A new system is assembled from ready bricks, not written from scratch.
The builder turns a problem model into services, screens and processes.
Delivery moves from months to days while the money circuit keeps its guards.

  • Low-code builder
  • Ready bricks
  • Deterministic generation
All solutions

Live screens from the product terminals

Generation run with the verifier verdict Generation run with the verifier verdict Presets studio with the assembled system Presets studio with the assembled system Solution model editor

Interactive builder

Open the builder

The builder is a working application, not a static page. Open the engine, pick a preset and assemble from ready bricks.

Open the builder →

Functions at a glance

Business functions at a glance

From the problem model to a running system.

Solution model
Keeps entities, fields, screens and processes as one source
The system and its documents always match
Brick catalog
Lists backend, frontend and rule bricks with parameters
Teams assemble from what already exists
Model validation
Checks structure and cross-references before generation
An inconsistent system cannot be assembled
Deterministic generation
Builds services, screens, tests and deployments from the model
The same model gives the same result
Verification layer
Runs guards, UI audit and money invariants
Defects stop before release
Runtime metadata
Changes the typical part without a rebuild
Routine changes need no release
Process and rules
Keeps states, transitions, actors and calculations declarative
Processes change without hand coding
Open interfaces
Exposes the model by MCP, CLI and open schema
AI and partners work on one contract

What runs today

Assemble, not develop, already running

Assemble, not develop: the live builder.

Model

Entities, screens and processes live in one governed model.

Bricks

The catalog holds backend and frontend bricks with schemas.

Generation

Services, screens and tests are generated deterministically.

Verification

Guards and invariants approve or block every run.

Runtime

The typical part changes by configuration, without a rebuild.

Interfaces

MCP, CLI and JSON Schema connect AI and partner tools.

Solution description

Capabilities and overview

Key features

  • Solution model: entities, fields, screens and processes
  • Brick catalog with parameter schemas
  • Brick suggestion by model entities and screens
  • Model validation and cross-reference checks
  • Deterministic backend and frontend generation
  • Test generation with negative cases and boundaries
  • Deployment manifests generated from the model
  • Verification: guards, UI audit and money invariants
  • Runtime metadata for the typical part
  • Process and rules engines
  • MCP server, CLI and open JSON Schema
  • Roles, review and action audit

Product overview

Unifin Architect Builder is a low-code builder of new systems for venues, banks and their IT teams.

It turns a solution model into services, portals, migrations, tests and deployment manifests from ready bricks.

The builder is deterministic: the same model gives the same result, and manual edits survive a re-run through markers.

It sits on the UniFin platform, so the assembled system reuses the shared identity, audit, approval and event backbone.

The result is a deployable solution, not a prototype: services, screens and documents come from one source.

Related solutions

Unifin Desktop Kit

The workspace engine: widgets, the desk constructor, tabs, four themes and white label. A new screen arrives as a widget on the assembled system.

Unifin Charts

An own charting library with chart types for every class of asset. Charts embed into a builder screen through the public API.

Unifin Stock Exchange

The exchange end to end: front, middle and back office, reporting, surveillance and the broker solution on one core.

What it delivers

What the builder delivers

From the model to the running system, brick by brick.

Solution model

Systems are usually described in scattered documents that drift from the code. The builder keeps entities, fields, screens and processes as one model with versioning. With the solution the model is the source of truth, and the system matches it. In setup the model is visible, reviewable and versioned, and the history comes with it.

Brick catalog

Every new screen usually starts from a blank file. The builder suggests bricks by the entities and screens of the model. With the solution teams assemble from bricks that already passed the platform guards. In setup the catalog, groups and parameter schemas are visible, and the set of bricks comes as a catalogue.

Deterministic generation

Delivery usually depends on who writes the code and when. The builder generates services, screens, tests and deployments from the model. With the solution the same model gives the same result on every run. In setup the generation markers and the diff preview are visible, so manual edits survive a re-run.

Verification layer

Generated code usually reaches review without proof of safety. The builder runs guards, UI audit and money invariants on what it produces. With the solution a defect stops before release, not in production. In setup the verdicts and evidence are visible, and the money path stays codegen only.

Runtime metadata

The typical part of a system usually waits for the next release. The builder keeps pages, forms and lists as versioned runtime metadata. With the solution a dictionary or a list changes without a rebuild. In setup the metadata and its versions are visible, and the change audit records who moved what.

Process and rules

A process change usually becomes a development task. The builder keeps states, transitions, actors and rules declarative. With the solution a workflow changes by configuration, under four eyes. In setup the process definition and the decision tables are visible, and the actors come from the role canon.

Open interfaces

A constructor usually locks the customer into its own tooling. The builder exposes the model by MCP, a CLI and an open JSON Schema. With the solution AI assistants, CI and partner tools work on one contract. In setup the schema, the CLI and the server are visible, and the output stays ordinary code.

Coverage

What it covers

From the model to services, screens and deployments.

Solution model

Entities, fields, screens, processes and roles as one versioned model.

Brick catalog

Backend, frontend, rule, report and integration bricks with parameter schemas.

Generation

Services, migrations, screens, tests and deployment manifests from the model.

Verification

Guards, UI audit, mutation and money invariants with one verdict.

Runtime

Page metadata, the process engine, rules and the change audit.

Interfaces

MCP server, CLI and the open JSON Schema of the model.

Stand

Screens of the solution

The presets studio, the brick catalog and the assembled system under one roof.

Presets studio with the assembled system
Presets studio: the assembled system on one canvas
Brick catalog dashboard
Brick catalog with readiness and coverage
Solution model editor
Solution model editor: entities, fields and screens
Generation run with the verifier verdict
Generation run: the diff preview and the verifier verdict

How it works

From the problem model to a deployable system in five steps

From the problem model to a deployable system.

  1. 1

    The model is described

    Entities, fields, screens and processes are defined once.

  2. 2

    Bricks are suggested

    The catalog proposes bricks by entities and screens.

  3. 3

    The result is previewed

    A diff preview shows what will be created.

  4. 4

    Artifacts are generated

    Services, screens, tests and manifests are built.

  5. 5

    The verifier gives a verdict

    Guards and invariants approve or block the release.

Industries

Industries it serves

The builder serves venues, banks, depositories and integrators who assemble new financial systems from ready bricks.

Architecture

Architecture and access

The builder lies on the common base of the platform and drives code, metadata and documents from one model.

On the platform base

Shared identity, audit, approval and the event backbone.

Model as the source

One versioned model drives code, metadata and documents.

Deterministic generation

The same model gives the same result; markers keep manual edits.

Verification first

The money path is codegen only, with guards and invariants.

AI layer

The AI composer proposes the model and bricks, and is checked by the verifier.

Architecture scheme The same architecture as a standalone page. Open the diagram separately

Readiness

Ready today, next in line

The builder runs on the platform; next: partner bricks.

Ready today

  • Solution model, versioning and validation
  • Brick catalog with parameter schemas
  • Deterministic backend, frontend and test generation
  • Verification: guards, UI audit and money invariants

Next in line

  • Partner brick marketplace (roadmap)
  • Visual model editor variants for every role (roadmap)
  • External tool connectors by open contract (roadmap)

Releases

Release history

Quarterly releases from the foundation of the platform (2020); the builder line starts in 2026.

2026 Q2

  • The solution model, its validation and versioning.

2026 Q3

  • The brick catalog, deterministic generation and the verification layer.

2026 Q4

  • The presets studio, runtime metadata and the open contract (plan).

Detailed description

Detailed description

The layer map, the guarantees and the delivery frame.

How the suite is assembled

Channels and clients
FIX 4.2 / 4.4 / 5.0, REST with mTLS, SFTP files, web portals
Edge and access
API gateway with 126 routes, Keycloak single sign-on, WAF and CSP
Platform core services
solution model brick catalog generator verifier AI agentic layer Services of the suite on the shared platform core
Data and events
PostgreSQL 17 per service, Redis 7, RabbitMQ 3.13 quorum queues, transactional outbox
Results and reporting
Portals, reports, regulator and partner channels

Technology stack

Runtime and backend: Java 21 (LTS), Spring Boot 3.5.16, Gradle, Flyway; generated services follow the platform template.

Model and contract: JSON Schema with an open specification, versioned in git, exported to specifications and documents.

Portals: Next.js 16.3.3 and React 19 for the constructor surfaces; the UI follows the platform design system.

Solution model

  • One model holds entities, fields, screens, processes and roles; it is the source of truth for code, metadata and documents.
  • Validation checks structure and cross-references: a screen to an entity, a reference to an entity, a transition to a state, a role to the role list.
  • Versioning gives commits, diff, rollback and branching; import comes from a brief, spec-kit, OpenAPI or a spreadsheet.
  • A drift check compares the model with the code and the registries, so the two never drift apart silently.

Bricks and generation

  • The brick catalog lists backend, frontend, rule, report and integration bricks with a parameter schema and a compatibility check.
  • Brick suggestion recommends a composition by the entities and screens of the model, so teams start from what exists.
  • Deterministic generation builds services, migrations, screens, tests and deployment manifests; markers keep manual edits on a re-run.
  • A diff preview shows what will be created before anything is written, so the run is a decision, not a surprise.

Verification

  • Guards run on generated code and configuration; a canon violation blocks the release instead of reaching production.
  • UI audit runs portal passes and probes for locales, contrast, geometry and accessibility.
  • Mutation testing checks the strength of tests on the money circuit, and money invariants check financial processes.
  • One consolidated verdict returns BLOCK or APPROVE with evidence, so the run has a single clear status.

Runtime and interfaces

  • Runtime metadata keeps page, form and list configurations versioned, so the typical part changes without a rebuild.
  • The process engine keeps states, transitions, actors and rights; the rules engine keeps declarative rules and calculations.
  • The model is exposed by an MCP server, a CLI and an open JSON Schema, so assistants, CI and partner tools work on one contract.
  • Roles and review separate administrator, architect, analyst, engineer and viewer with comments and action audit.

Architecture

  • Six layers: the model, the brick catalog, generation, runtime, verification and the interfaces on top.
  • The builder stands on the platform base: identity, audit, approval, day schedule and the event backbone.
  • The money circuit runs through codegen only, under guards and invariants; secrets live only in the vault, never in the model.

Integrations and access

  • MCP tools cover solution, brick, generation and validation calls for assistants and partners.
  • The CLI covers build, validate, generate and verify, so the constructor plugs into CI and the terminal.
  • The open JSON Schema of the model and bricks lets third-party tools integrate without vendor lock-in.
Detailed description

Leave your contacts to open the detailed description and download the PDF with architecture, cases and delivery details.

Assemble a system from ready bricks

Tell us the problem: we will bring the model, the brick set and the verifier for a first assembled solution.