Banking and Qard al-Hasan fund infrastructureon one Financial Core
In Dara, deposits, financing, cards and wallets keep no separate balances. Every rial is posted to one Financial Core, and processes run on an engine where changing them does not require a new software release.
- Fifteen Islamic contracts with dedicated calculators
- Installment schedules on the Solar Hijri calendar
- Auditable, from vouchers to AI assistant answers
A platform built from a single blueprint
All Dara services share the same layered structure, response format and method for posting vouchers. That is why adding a new module is a repeatable task.
Runtime services
All with the same layered structure
Domain modules
Each owns its own data
Callable operations
Exposed by the modules
Domain events
Published for other modules
No module keeps its own balance
Deposits, wallets, cards, financing and the investment portfolio read balances from the Financial Core and post their financial impact there as vouchers. As a result, reconciliation between subsystems drops out of the end-of-day routine.
- 01
Posting with an idempotency key
If a posting request arrives a second time, for whatever reason, no duplicate voucher is created.
- 02
Three-stage vouchers
Draft, provisional and final, with a voucher sequence number that runs consecutively within each fiscal period and never runs backward.
- 03
Up to six detail levels
Every deposit account, wallet and financing contract has a dedicated detail account in the same chart of accounts.
Dara solutions
Every solution is built on the same Financial Core and the same Process Engine. You can start with one and add the rest later.
Layers with clear boundaries
Each layer has a specific job and talks to its neighbors only through defined contracts.
- 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
Change processes in the designer
In Dara's engine, every process graph is versioned data. A new version is published with a single call, and in-flight cases continue on their own version.
- 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.
An assistant that sees what you see
Dara's AI assistant works with the same permissions and the same data the user has in the portal. Its answers cite their sources, and it commits no action without human approval.
Dara Assistant
With the signed-in user's own permissions
No new access level is created
The assistant sees only the data the user would see after signing in to the portal.
No change without human approval
Posting vouchers, deactivating accounts, publishing processes and sending correspondence all wait for the user's explicit approval.
Calculations come from the system
Totals, trial balances, account balances and days overdue are computed by the system. No figure comes from model-generated text.
Credit and identity decisions stay with people
Final identity verification is never automated, and neither is any credit or pricing decision.
Sourced answers, recorded actions
Each answer states which voucher it came from and under what condition, and every action is recorded in the audit trail.
Bounded execution
If running a request exceeds the allowed number of steps, execution stops and a manager decides what happens next.
The organizations we build for
A Qard al-Hasan fund, a bank and a fintech company need different things. The page for each group explains which of its problems Dara solves.
The difference in day-to-day work
A few familiar situations in financial systems, and how Dara handles them.
Security and audit built into the design
Every request, voucher and action follows a predefined path. These principles are applied the same way in every Dara module.
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.
Latest articles
Dara news, and notes from our team on architecture, product and banking know-how.
See the platform run your organization's own scenarios
In an introductory session we walk through the demo environment together, from opening a deposit account to disbursing a loan and closing a period, and answer questions from your technical and finance teams.