WEFI architecture overview

WEFI separates three concerns. Business applications — EDOS, Loan OS, Sahara, Broker and organisation-specific applications — define the business experience. Platform capabilities — Runtime, Policy, AI and Integration — provide execution, governance, intelligence and connectivity that every application shares. Systems of record — core banking, ERP, CRM, payments — remain authoritative for the data they own.

Dependencies point downwards: applications use platform capabilities; platform capabilities never depend on a specific application. Applications are independently deployable, so an institution can adopt one without taking all of them.

Applications and processes never call a vendor interface directly. They call stable WEFI contracts; WEFI Integration implements those contracts with provider-specific adapters. Changing a bureau, payment provider or core system means changing an adapter, not the business process.

APIs

REST APIs for commands and queries between applications and to external systems.

Events

Business events published to an event backbone so other services and analytics can react without tight coupling.

Data authority

For each data type the institution designates an authoritative system. Other components read projections and send authoritative changes to the owner.

File exchange

Structured file exchange where a system does not offer APIs — common with insurers and some legacy cores.

WEFI Runtime executes business processes from explicit process models (BPMN). Process stages are defined in the model, not hard-coded in application code, so stages, routing and escalation can change through governed release.

Orchestration

Process instances coordinate automated steps, human tasks and calls to other systems.

State management

Business entities move through defined states; every transition is validated and published as an event.

Human tasks

Work is assigned to roles with service levels, escalation and approval chains.

Auditability

Each instance retains its history: who did what, when, and with which data and rule version.

WEFI AI runs agents as defined steps within WEFI Runtime processes rather than as free-standing assistants. Agents are registered with their purpose, tools and configuration; executions are tracked; and outputs that need judgement go to a human review queue where they can be accepted or overridden.

• Agent registry and executionAvailable
• Human-in-the-loop review and overrideAvailable
• Guardrails and audit eventsAvailable
• Retrieval over enterprise knowledgeIn development
• Agent memoryIn development
• Tool access via Model Context ProtocolIn development

WEFI Policy holds business decisions — credit rules, eligibility, pricing conditions, approval authority — as versioned decision definitions, separate from application code. Processes request a decision; WEFI Policy evaluates it and returns the outcome with the version applied. Policy evaluation uses the open-source Open Policy Agent as an evaluator alongside WEFI's own decision definitions.

Versioning

Every change creates a new version; the version used is recorded with each decision.

Validation

Decision graphs are validated before a version is released; scenario testing tooling is in development.

Authorisation

Who may change, approve or override a rule is itself controlled.

Audit

Inputs, outcome and version are retained for each evaluation.

WEFI services are containerised and use PostgreSQL databases with each service owning its own data. Services communicate through APIs and the event backbone, and authenticate users through an OpenID Connect identity provider.

Hosting options

A WEFI-managed environment, or the institution's own data centre or private cloud, agreed per engagement.

Environments

Separate development, test/UAT and production environments.

Modular deployment

Only the applications and capabilities an institution licenses are installed and enabled.

Infrastructure requirements

Container orchestration, PostgreSQL, an event backbone and identity provider; sizing is confirmed during design.

Security is designed in at the platform level so every application inherits the same controls. Specific controls — network design, encryption and key management, backup and disaster recovery — are agreed per deployment to meet the institution's policies and regulatory obligations.

Identity

Single sign-on through OpenID Connect, integrating with the institution's identity provider.

Access control

Role-based permissions scoped to the organisation structure; navigation and actions reflect each user's role.

Tenant isolation

Licensing, installation and data are scoped per institution.

Audit

State transitions, decisions, approvals and AI actions are recorded for review.

Data protection

Institutions remain data controllers; WEFI processes data on their instructions under the engagement agreement.

Secure delivery

Environment separation and governed promotion of changes to production.

Read our security approach

Discovery maps products, processes and existing systems and agrees which system is authoritative for each type of data. A first release is scoped to one product line, process or branch so that value and risk are proven before extension.