The Dara Platform
One Financial Core, one Process Engine and a shared infrastructure that every module is built on. Here we explain what each part does and why it is designed the way it is.
Design principles
Every Dara service follows these principles, and they account for most of how the platform behaves.
- 01
One core for all balances
No module keeps a local balance. The deposit, wallet, financing and investment portfolio modules read balances from the Financial Core and post their vouchers there. A multi-level chart of accounts with floating detail accounts, plus an idempotency key on every posting, makes this core the single authoritative record.
- 02
Process as data
Each process graph is stored in a data column and, like any other data, is versioned, validated and published. Reordering tasks or adding an approval step is a process-design decision and does not call for a build-and-release cycle across several services.
- 03
Identity separate from authorization
The Identity module issues tokens; memberships, roles and the permission catalog belong to the Users & Companies module. Tokens are validated only at the gateway, and after inbound headers are sanitized, the user's verified details are attached to the request.
- 04
Each module owns its data
A module's boundary is also its database boundary, and no module writes directly to another module's tables. Each module exposes two things to the outside world: callable operations and published events.
- 05
One pattern across all services
Every domain service shares the same layered structure, response format, pagination contract and request-processing order. That uniformity keeps the code easy to read and maintain, and makes adding a new module a repeatable task.
Platform layers
From the customer app down to the infrastructure, each layer has a clearly defined responsibility. The Financial Core sits in the middle, and every layer above it relies on it for balances.
- 01
Experience layer
The customer app, organization portal, merchant portal and back office. All of them work directly on the data recorded in the Financial Core, and none keeps a separately synced copy.
- Customer app
- Organization portal
- Merchant portal
- Back office
- 02
Domain modules
Deposits, financing, cards, wallets and collateral each have their own database. No module writes to another module's tables; they interact through callable operations and published events.
- Deposit
- Financing
- Card
- Wallet
- Collateral
- Merchant
- 03
Process Engine
Each process graph is versioned data. Staff work queues, timers and coordination between modules all run in this layer.
- Process Designer
- Work queue
- Durable timer
- Event outbox
- 04
Financial Core
The single source of truth for balances: a multi-level chart of accounts with floating detail accounts, three-stage vouchers and fiscal periods with non-resettable numbering.
- Chart of accounts
- Voucher
- Fiscal period
- Floating detail account
- 05
Infrastructure
A single ingress gateway, identity kept separate from authorization, service registry and discovery, encrypted document management and centralized logging.
- API Gateway
- Identity & authorization
- Service discovery
- Document Management
- Centralized logging
Process Engine
Dara's Process Engine keeps the state of each case in the simplest possible form. Reading the current state is one simple query, with no history to replay.
- 01
Processes as versioned data
Each process moves through draft, published and archived states. Publishing a new version takes a single call and does not require redeploying any service. In-flight cases stay on their own version.
- 02
Atomic advance behind a case lock
Each step advances inside a transaction that first acquires the lock on that case. If several modules respond at the same time, their responses queue behind that lock, so the case never ends up in two conflicting states.
- 03
Event and state in one transaction
A state change and the event announcing it are committed together, or neither is. Events are delivered separately, HMAC-signed and retried with increasing back-off.
- 04
Human work queues and deadlines
Human tasks are created with a target role and a geographic scope, and can be claimed, completed, returned or reassigned. Timers are durable and survive a service restart.
- 05
Eighteen node types
They range from human tasks and timers to calls to external systems. A process analyst draws the graph in the visual designer and assigns a role and a deadline to each human task.
- 06
Validation before publishing
Before a graph is published, it is checked for dead-end steps and unfinished paths. Errors show up right in the designer.
Shared infrastructure
Domain modules run on these shared services, and none of them repeats this work on its own.
Identity
User sign-in and access-token issuance for the entire platform happen in this module and nowhere else.
API Gateway
The only entry point for requests to the modules. Tokens are validated here, and each request is routed using the service registry.
Document Management
Files and supporting documents are stored with layered encryption in a storage location of your choice.
Notifications & Messaging
SMS, email, push notifications, the in-app inbox and one-time passwords, all sent from a single outbound point.
Central Scheduler
Scheduled jobs for every module run from one scheduler, while the logic of each job stays with the module that owns it.
External Services Hub
Every call to systems outside the organization goes through a defined route that can be configured and monitored.
Security and audit
Security in Dara comes down to a few simple principles, applied the same way in every module: a single entry point, identity separate from authorization, irreversible vouchers and a complete history.
A single entry point
No request reaches the modules without passing through the API Gateway. Tokens are validated there, and inbound headers are sanitized.
Identity separate from authorization
Tokens are issued by the Identity module, while roles and the permission catalog are defined in the Users & Companies module.
Irreversible vouchers
A final voucher cannot be edited, and voucher sequence numbers run consecutively within each fiscal period, with no gaps.
An idempotency key on every posting
Voucher postings, funds transfers and purchases each carry an idempotency key, so a repeated request never takes effect twice.
Encrypted documents
Files and documents are stored with layered encryption in the Document Management module. Other modules hold only the file ID.
Operations history
Case transitions, user actions and AI assistant answers are recorded along with their sources and remain available for audit.
The technologies we work with
The platform is built on technologies already familiar from the infrastructure of Iranian financial institutions, and it can run on an institution's own servers.
Backend
01- .NET 10
- ASP.NET Core
- Node.js
User interface
02- Next.js
- React
- TypeScript
Data and messaging
03- SQL Server
- PostgreSQL
- Redis
- RabbitMQ
Deployment and routing
04- Docker
- GitLab CI/CD
- YARP
- Eureka
Logging and monitoring
05- Serilog
- Elasticsearch
- Seq
- Prometheus
From the discovery session to go-live
Every project starts by getting to know the institution's current systems and procedures, and go-live waits until balances and cases have been reconciled against the legacy system.
- 01
Discovery and analysis
We go through the institution's products, processes, chart of accounts and current systems together, and list the gaps and open decisions before anything is configured.
- 02
Design and configuration
Deposit categories, credit lines, voucher templates, roles and approval processes are set up on the platform. Any requirement that falls outside the existing capabilities is identified and scheduled at this stage.
- 03
Data migration and testing
Balances and open cases are migrated from the legacy system and reconciled against its reports. Key users run their day-to-day scenarios in the test environment.
- 04
Go-live and support
Once the reconciliations are approved, the legacy system is shut down on cut-over day and work continues on Dara. User training, documentation and post-go-live support are part of every project.
Let's review the architecture with your technical team
If your technical team wants to go into the details of the architecture, deployment and integration with your existing systems, we will arrange a technical session.