Available now
In build
The whole team
Nineteen specialists, each with a defined job and an honest status label.
See all nineteenDena reads a bank account or a bank statement a person already has a right to see, and answers questions about it. It cannot touch the money.
Dena is an information-only layer over a workspace's own banking data — consented account links, imported statements, balances, transactions and the questions a person actually asks about them. It is a regulated agent under this product's own domain model (Domain.BANKING), and it is built to the narrowest boundary of any agent in this product: every route either displays, explains, flags or exports. None of them move money, none of them assess creditworthiness, and none of them give financial advice. Each prohibition is an absence in the schema, not a rule enforced only in prose — no payee or mandate column exists to send a transfer through, no score column exists to hold a credit assessment, and there is no table where a persisted, dated, priced instalment could sit waiting to go out.
Dena, Laxmi and Khata each model money, and a person will experience the three as overlapping. Dena is the one for reading a bank account or a statement and asking what it says — it never touches an invoice, a bill or a ledger. Laxmi is the one for running the business day to day. Khata is the one that gets the books into a state an accountant can sign off on. They are three separate registers today: a statement imported into two of them lands in two places that never reconcile with each other, and the gap is not cosmetic — an internal 2026-08-16 review found that Dena masks account numbers in statement narrations and Khata does not, so importing the same bank file into both agents, which the product actively invites, can defeat Dena's no-credential-storage guarantee from inside the same product. There is an open decision about whether the three should merge — see docs/REQUIRED_FROM_USER.md §3.6. Until then: pick Dena for reading a bank account, Laxmi for running the business, Khata for accountant handoff, and do not expect the same statement imported into more than one of them to agree with itself.
It cannot move money, under any name
No route can send, schedule, authorise or reverse a transfer, a standing instruction or a mandate. The recurring-payment detector only observes what already happened — nothing in it creates, changes or cancels a standing instruction.
It does not decide creditworthiness
The loan-readiness checklist reports six documentation categories as present, missing, unknown or not applicable — nothing else. There is no score, no eligibility verdict, no approval probability, no rate estimate and no lender named anywhere in its response, because those are lending decisions and Dena is not a lender.
It does not advise
Asking the banking glossary an advice-shaped question — 'should I take this loan', 'which bank is best', 'pay this vendor for me' — is refused before an answer is composed, with a redirect to a licensed adviser or the owner's own bank. Whatever answer does get composed is then re-checked against the same banking gate before it is returned.
It stores at most a masked four-digit card tail — a full number is refused outright
Any field that looks like a full card number — sixteen digits that pass a Luhn check — is rejected before it is stored. What Dena is allowed to hold is the last four digits, and the column that holds them is physically four characters wide, so the refusal is not only in the application code.
An amortisation schedule is computed on the spot, never stored
A table of dated, priced instalments with a status column is the exact shape of an outbound payment queue, so Dena keeps no such table. Every schedule is recomputed from the loan's recorded terms on every read, and a recorded payment has no due date, no scheduled-for field and no status — because there is no state in which one of those rows is waiting to happen.
It never stores a banking credential
No net-banking login, password, PIN, OTP or MPIN can be written through any Dena route — a guard runs on every free-text field on every write path and refuses anything that looks like a labelled secret. The only path to live data is a consent the account holder grants inside their own bank's or aggregator's own screen, never a Dena-branded one.
Getting started
Add the account with, at most, its masked four-digit tail — never a full number, never a login. Nothing here connects to the bank yet; it only tells Dena which account any statement or consent you add next belongs to.
Import parsed transaction rows directly — narrations are masked of long digit runs on write, because Indian statement narrations routinely carry a counterparty's account number — or compose a consent request with its purpose, scope, date window and expiry. The consent stays 'requested' until the account holder approves it inside their own bank's or aggregator's screen; no route in Dena can approve it for them.
Read the balance view, the cash-flow summary, the recurring-payment list or the loan-readiness checklist, or ask the glossary a plain-language question. Every answer states what it does and does not know, and an advice-shaped question is refused with a redirect rather than answered.
Capabilities
Purpose, scope, data window, expiry and fetch frequency are all columns, and a request cannot ask for more scope than its stated purpose needs. No route can approve a consent — that happens inside the owner's own bank or aggregator screen.
Needs: an RBI-licensed Account Aggregator client before any data can actually flow
Revocation is recorded immediately, not after a third party answers. The audit log reads the platform's own append-only events, so it is not a log Dena could rewrite, and it records the fact of an access, never an identifier.
Status and counts by state for every request in flight. A webhook route now receives a status update, verifies its HMAC-SHA256 signature, applies only the transitions an Account Aggregator may make, and is idempotent by event id — with a queryable status history per consent, and a consent past its expiry swept to expired the next time the inbox is read.
Needs: A webhook signing secret (DENA_AA_WEBHOOK_SECRET) from your Account Aggregator, which isn't set on this deployment. Flagged honestly: this HMAC scheme may still need swapping once a specific AA vendor is chosen — several sign with JWS and a certificate chain instead.
Each balance carries its own age and is marked stale past 36 hours, and is totalled per currency — never merged into one misleading figure. A refresh cadence can now be set per account, checked against that account's own consent so a schedule can never outrun what was actually authorised, and requesting a refresh records a real, timestamped attempt.
Needs: Pulling an actually fresh balance needs an Account Aggregator client, which is unbuilt integration code, not a missing key — every refresh attempt today honestly reports not_configured. Balances are owner-entered or statement-imported until then.
Import de-duplicates by content hash and filters by account, date, direction, amount band and free text. Narrations are masked of long digit runs on write. A search route now takes the same filters as a JSON body for multi-value queries a query string can't express, and a keyword-rule classifier — not an NLP model — fills in a blank category on import while the owner's own category always wins; category_source records owner vs auto so a guess is never mistaken for a fact.
By day, week or month, plus per-category totals. The narrative is filled from templates over the real totals, not written by a model, and passes through the banking gate before it is returned.
By counterparty and cadence, with the next date always labelled an estimate. Nothing here creates, changes or cancels a standing instruction or mandate.
Two closed question templates — the lowest balance in a named month, spend to a named counterparty in a period — now answer for real from the workspace's own imported transactions, each fact citing the row it came from, with the conversation saved and an out-of-scope question refused before an answer is even attempted. Both answer per account and per currency rather than across everything at once: a workspace holding an INR current account and a USD account gets one labelled figure for each, because a lowest balance picked across two currencies is a comparison of incomparable numbers.
Needs: Free-form phrasing outside those two templates needs an LLM key, and reading an uploaded PDF's text at all needs an OCR service — neither client exists in this codebase, so unsupported is an honest answer today rather than a credential-gated promise.
Running-balance tally, duplicate entries, date ordering, period gaps and round-figure clustering, each flag carrying its evidence. There is no verdict column, and every response states plainly that it certifies nothing. When a caller supplies the document's own bytes inline (base64, size-capped, never stored), byte-level checks now run in memory too — multiple end-of-file markers, a modification date before the creation date, more than one producing application — each advisory, none a verdict, and needing no library, credential or object storage.
Compiles accounts, transactions and totals for a period into one watermarked payload. Deliberately not saved — a stored export is a second copy of transaction detail with its own retention problem, which is also why there is still no GET /exports/{id} or download route by design. All three formats render on request from one compiled payload and report amounts in minor units, so they cannot disagree about a figure. The PDF is written directly from the standard library rather than handed to a rendering service, so nothing extra is pinned and no native binary joins the container. Deliberately absent: no embedded fonts or logo, and no signature or encryption — a signed PDF is an attestation, and the watermark on every page says Dena attests to nothing.
Computed for a period against the figure the owner supplies, with the standard caveat about non-turnover credits — never a tax opinion. The declared figure is now persisted through a refresh route instead of being re-typed on every read, and is read back automatically when a caller supplies none inline.
Needs: An automatic fetch from GSTN or a GST Suvidha Provider is not built — the source column exists for it but nothing writes it yet, since that needs a real client written, not a key pasted in. The owner supplies the turnover figure until then.
Six categories reported as present, missing, unknown or not applicable against what is actually in the register. No score, no eligibility, no rate, no lender.
Per account, written to an event log the owner can read. The event has no column for an offer or a partner.
Needs: a notification provider to actually deliver an alert — evaluation and the event log work without one
Timing, typical limits and normal use, attributed to published RBI and NPCI guidance and stamped with the date a person last reviewed them. Curated in code, so a figure cannot change without a diff and a reviewer.
Answered from a closed catalogue. Advice, eligibility and 'pay this for me' questions are refused with a redirect before an answer is composed.
An owner invites an email address to a read-only link — a bearer token, hashed at rest, never a second platform login — defaulting to the narrower summary_only role; a viewer additionally reaches the consolidated export, and neither role can ever reach a raw transaction's narration or counterparty. Inviting, changing a role and revoking immediately are all real against Dena's own tables, and the access log reads the platform's own append-only audit trail.
API surface
Every route below is mounted and reachable today. Requests and responses are real shapes, not illustrations.
Nothing here can approve itself, and nothing here can hold more than a masked identifier.
/api/v1/agents/dena/consentsCompose a consent request — scope is validated against the stated purpose (HTTP 201). A scope wider than the stated purpose needs is refused before the row is even written — requesting transactions for a purpose that only needs balances does not pass validation.
Request
{
"bank_name": "HDFC Bank",
"purpose": "cash_flow_review",
"scope": [
"balances",
"transactions"
],
"data_from": "2026-02-16",
"data_to": "2026-08-16",
"expires_on": "2026-11-16",
"fetches_per_month": 4
}Response
{
"id": "cst-1",
"status": "requested",
"data_flow": "none",
"requires_configuration": "An RBI-licensed Account Aggregator client (Sahamati-standard AA API credentials) is needed before this request can reach the owner's bank."
}/api/v1/agents/dena/accountsA full card number is refused outright — only a masked tail is stored (HTTP 422). A four-digit tail ("1111") passes; anything longer is refused with 'Dena stores at most the last four — send those, or leave it blank.' The database column backing this field is physically four characters wide, so the refusal holds even if the application check were removed.
Request
{
"label": "Business card",
"masked_tail": "4111111111111111"
}Response
{
"detail": "'masked_tail' looks like a full card number. Dena stores at most the last four digits."
}What was recorded or imported, marked with its own age, and masked before it is stored.
/api/v1/agents/dena/balancesLatest balance per account, marked stale, totalled per currency (HTTP 200). That balance is INR 8,420.00, recorded over a day and a half ago — past the 36-hour freshness window, so is_stale is true.
Response
{
"items": [
{
"account_id": "acc-1",
"balance_minor": 842000,
"currency": "INR",
"observed_at": "2026-08-14T18:00:00Z",
"age_hours": 40.2,
"is_stale": true,
"source": "owner_entry"
}
],
"totals_by_currency": {
"INR": {
"total_minor": 842000,
"accounts": 1
}
},
"stale_after_hours": 36,
"note": "Balances are what was last recorded, not a live figure from the bank, and are never combined across currencies."
}/api/v1/agents/dena/accounts/{account_id}/transactions/importImport statement rows — long digit runs in the narration are masked on write (HTTP 200). mask_long_digit_runs() replaces every run of eleven or more digits in the narration with "xxxx" plus its own last four digits, unconditionally, before the row is stored — a 14-digit counterparty account number embedded in a NEFT narration never reaches the database intact. Deduplication runs on a content hash, not a unique constraint, because two genuinely identical same-day payments are real and should both import.
Request
[
{
"txn_date": "2026-08-01",
"direction": "credit",
"amount_minor": 1500000,
"currency": "INR",
"narration": "NEFT CR-HDFC0000123-50100234567890-ACME TRADERS",
"reference": "UTR250801123456789"
}
]Response
{
"account_id": "acc-1",
"imported": 1,
"skipped_duplicates": 0,
"submitted": 1
}A schedule computed fresh every time, a checklist with no score, and a rail Dena cannot touch.
/api/v1/agents/dena/loan-readiness/checklistDocumentation completeness only — no score, no verdict (HTTP 200).
Response
{
"items": [
{
"key": "bank_statement_span",
"label": "Bank statement coverage",
"requirement": "6 months",
"status": "present",
"basis": "182 days imported"
},
{
"key": "income_tax_return",
"label": "Income tax return on file",
"requirement": "Latest filed ITR",
"status": "missing",
"basis": "no document registered"
},
{
"key": "gst_returns",
"label": "GST returns on file",
"requirement": "Last 3 filed returns",
"status": "unknown",
"basis": "no GST document category registered"
}
],
"counts": {
"present": 1,
"missing": 1,
"unknown": 1,
"not_applicable": 0
},
"disclaimer": "This is not a credit assessment: Dena holds no bureau data, does not estimate eligibility, approval chances or an interest rate, and does not suggest a lender. Your bank or NBFC decides all of that."
}/api/v1/agents/dena/reference/payment-rails/upiA curated explanation of one payment rail, dated and attributed (HTTP 200).
Response
{
"rail": {
"rail_id": "upi",
"name": "UPI (Unified Payments Interface)",
"typical_timing": "Instant, 24x7 including holidays.",
"typical_limits": "Commonly up to INR 1,00,000 per transaction, set by the bank and NPCI."
},
"attribution": "Summarised from guidance published by the Reserve Bank of India and NPCI. Limits and cut-offs change; confirm current figures with your own bank.",
"reviewed_on": "2026-08-16",
"disclaimer": "Dena cannot send, schedule or authorise a transfer on any of these rails. To actually move money, use your own bank's app or net-banking portal."
}/api/v1/agents/dena/loans/{loan_id}/scheduleAn amortisation schedule, recomputed from recorded terms on every read (HTTP 200). An instalment here is INR 9,500.00. This route sits outside the capabilities.py status table — it is real and tested, but not yet tracked by a slug there, so it is shown as evidence for the "recomputed, not stored" refusal above rather than as a graded capability. Recording a payment (POST /loans/{id}/payments) refuses a future-dated paid_on with 422: "A payment can only be recorded after it has been made."
Response
{
"loan_id": "ln-1",
"currency": "INR",
"instalment_minor": 950000,
"instalment_source": "lender-stated",
"schedule": [
{
"number": 1,
"due_on": "2026-09-01",
"payment_minor": 950000,
"interest_minor": 350000,
"principal_minor": 600000,
"closing_balance_minor": 49400000
}
],
"note": "Computed from the terms recorded for this loan. Dena cannot pay an instalment, set up an auto-debit, or tell you what a lender will do."
}Limits and gotchas
Every balance and transaction today is owner-entered or statement-imported. A scheduled pull straight from the bank needs the Account Aggregator client this deployment does not hold.
Every integrity-check response carries certifies_authenticity: false. A flag is worth a second look, not a verdict — even the byte-level checks that now run when the document's own bytes are supplied inline are advisory, and imported rows with no original file attached only ever get the checks that work on parsed rows.
HMAC-SHA256 over the raw body is the simplest correct scheme, not necessarily the one a real, eventually-contracted Account Aggregator uses — several sign with JWS and a certificate chain instead, so this may need swapping once one is chosen.
Neither the summary_only nor the viewer role can read a transaction's narration or counterparty text through a shared link — only the consolidated, already-masked figures. That is the same boundary shared-access-roles' own two roles enforce structurally.
The comparison is scoped to one currency at a time by the caller; any excluded currency is reported explicitly rather than folded silently into the comparison.
The eighteen curated terms need no credential. A free-text question runs an out-of-scope check before an answer is composed and a banking-output check after — an advice-shaped question is refused at the first gate, before any answer exists to check.
GET /api/v1/agents/dena/loans/{id}/schedule and the surrounding /loans and /product-terms routes are built and tested, but carry no capability slug in the backend's status module yet — treat this page's schedule example as evidence, not as a graded status claim.
What this needs from you
Everything else on this page works with none of these connected.
| Credential | Unlocks |
|---|---|
| An RBI-licensed Account Aggregator client | to let a consent actually reach the account holder's bank and pull live balances and transactions instead of relying on hand-imported rows |
| A webhook signing secret (DENA_AA_WEBHOOK_SECRET) | to verify a status update posted by your Account Aggregator and keep the account-linking inbox current automatically |
| An OCR service | to parse an uploaded statement PDF directly, rather than importing already-parsed rows |
| An LLM key | to ask a free-form natural-language question of an imported statement, beyond the two closed templates that already answer for real |
| A notification provider | to actually deliver a low-balance alert — the threshold evaluation and event log work without one |
| A document renderer | to render the consolidated multi-account statement to PDF instead of the CSV it already generates for real today |
Questions
Yes — invite their email to a read-only link. It's a bearer token, hashed at rest, never a second platform login, and defaults to a summary_only role; a viewer role additionally reaches the consolidated export. Neither role can ever read a raw transaction's narration, counterparty or bank reference — the export drops those three fields rather than relying on a caller to ask for less — and you can change the role or revoke the link instantly. The link points at the endpoint that actually serves the token (/api/v1/agents/dena/access/shared/{token}/summary) and answers JSON today, not a rendered page. If email delivery isn't configured, the same link is simply returned for you to share by hand — nothing about this needs a credential.
No. There is no route anywhere in Dena that can send, schedule or authorise a transfer, a standing instruction or a card transaction. It reads and explains; it does not act.
No. The loan-readiness checklist reports what documentation is present, missing, unknown or not applicable — nothing about your odds, an interest rate or which lender to approach. That is a lending decision, and Dena is not a lender.
Never a password, PIN, OTP or full card number — a guard checks every free-text field on every write and refuses anything that looks like one. A card number is refused outright; at most a four-digit tail can be stored, and the database column is physically four characters wide.
Nowhere, as a stored table. It is computed fresh from the loan's recorded terms every time you ask for it. A saved table of dated, priced instalments with a status column is the shape of an outbound payment queue, and Dena is built not to have one.
No — that question is refused before an answer is composed, with a note pointing you to a licensed adviser or your own bank. The glossary answers what a term means, not what you should do.
Depends on the job. Dena is for reading a bank account or statement and asking questions about it. Laxmi runs the business day to day; Khata prepares books for an accountant. The three keep separate registers today, so importing the same statement into more than one will not make them agree with each other.
Coming soon