Skip to content

Qard al-Hasan Deposit (Deposit)

Finance & Payments

The deposit account cycle from opening to deposits, withdrawals, transfers, closing and reactivation. Fees, transaction reversal and account dormancy are also handled in this service.

Domain
Banking deposits and Qard al-Hasan
Target customers
banks, credit institutions, financing companies
Main capabilities
opening, deposits, withdrawals, transfers, closing, holds, joint accounts, fees, dormancy and reactivation

The Deposit service is a standalone microservice for managing the full lifecycle of Qard al-Hasan deposit accounts. It covers opening, deposits, withdrawals, transfers, closing, transaction reversal, fees, dormancy and reactivation of a deposit account, and is designed for banks, financial institutions and credit companies that offer a Qard al-Hasan deposit product or something similar.

Operational deposit data (account, owner, restrictions, transaction history) is kept in the service's own dedicated database, but the financial posting of every operation is done centrally in the platform's accounting core. The balance of a deposit is therefore never stored separately. It is always computed from the Financial Core, so the balance shown to the customer always matches the company's financial accounts.

The service has dedicated APIs for both branch counter and support operations and for the customer mobile app, and it is integrated with the Financing service and the platform's credit scoring engine.

Key capabilities

  • Full deposit account lifecycle

    Opening (single or bulk, up to 2,000 rows in one request), deposit, withdrawal, internal and external transfer, closing and transaction reversal, all with self-contained deposit numbering and a check digit.

  • Deposit categories

    Different deposit categories (Qard al-Hasan, savings, current, institutional, financing collateral, wallet-backing, blocked and others), each with a balance ceiling, a minimum balance, a per-withdrawal limit and a cap on the number of active deposits per customer.

  • Joint accounts and signature levels

    Multiple owners on one account (primary owner, joint owner, legal representative, guardian, authorized signatory, supervisor) with a configurable signature rule: single signature, any one of the owners, all owners, the primary owner plus one other person, or a custom group.

  • Holds and restrictions

    Judicial hold, financing collateral hold, tax hold, inheritance attachment, manual hold and partial hold, each of which can be released separately. A deposit account can directly serve as collateral for a financing in the Financing service.

  • Fees

    Definable fee rules for opening, withdrawal, transfer and account closing, plus custom fees.

  • Dormancy and reactivation

    Marking an account as dormant and returning it to active status, with the reason for each change recorded.

  • Statement and real-time balance

    Inquiry of the total balance, the available balance (balance minus the required minimum and holds) and the full statement of each deposit, for both the branch counter and the customer app.

  • Integration with Financing and credit scoring

    Withdrawals tied to financing fees without posting a double voucher, and a daily balance data feed to the credit scoring engine.

  • Financial safety on retry

    A mandatory unique key (idempotency key) for sensitive monetary operations (account closing, bulk opening). Retrying after a network outage never creates a second voucher or a duplicate account, and a request whose content changes under the same key is rejected.

Business value

For a bank or financial institution, building Qard al-Hasan deposit infrastructure from scratch is costly and risky, especially in sensitive areas such as judicial holds, joint accounts and the link to financing collateral. Deposit provides this infrastructure ready-made and independent of the accounting core, while guaranteeing that no monetary operation is posted twice because of a network error or a user retry. The complete separation of operational deposit data from the accounting core allows independent development and also keeps the balance always aligned with the Financial Core.

Use cases

  • A bank or credit institution offering savings or current Qard al-Hasan deposits to customers.
  • Financing companies that hold a customer's deposit as collateral behind a financing.
  • Organizations that need to open accounts in bulk, for example for salary deposits or a customer acquisition campaign.
  • Managing dormant accounts and complying with regulatory requirements on inactive deposits.
  • Family or organizational joint accounts with a multi-person signature rule.

What sets it apart

  • The balance is never stored separately. It is always derived from the Financial Core, so the displayed figure and the financial reality cannot diverge.
  • Full retry safety on sensitive monetary operations, with a unique key and detection of different content under the same key.
  • Native support for joint accounts with multiple signature levels, matching real banking needs.
  • A direct connection to financing collateral and the credit scoring engine, with no separate integration work.
Get in Touch

See this module on demo data

In a demo session we walk through your organization's scenarios on Dara's demo environment and answer your technical and finance teams' questions.