How eKTextAI handles the student, parent and staff data a school puts into it — for schools and for parents.
Version of 20 October 2026 · India
For student, parent and staff data, the school is the Data Fiduciary under India's Digital Personal Data Protection Act, 2023 — it decides why and how the data is used and takes consent. MarvelSoft Ventures acts as the school's Data Processor: we process that data only on the school's written instructions and only to run eKTextAI for that school, under a Data Processing Agreement.
The school is the contact for parents on consent and privacy. We act on the school's instructions and never for our own purposes.
We process the data the school puts into eKTextAI in order to answer questions from parents, students and staff, and to run the features the school has switched on.
Setup takes from 30 minutes to a day. What decides which: how quickly the school provides its student and parent data and its circulars. eKTextAI works with no ERP at all — an ERP is not required and no integration is a condition of use. WhatsApp has two steps that are yours, in your own Meta account: Meta must approve the template you submit, and Meta will not send at all until a payment method is on that account. Your Meta billing is not ours.
Per student, held against the school's own account: admission number, father's name, mother's name, mobile number, email address, grade, section, status (active, inactive, transferred, graduated), date of birth — only if the school switches that field on. Plus audit fields (who created and last updated the record, import batch and timestamp) and the consent record (status, method, date recorded, who recorded it, notice version, withdrawal date).
The service also processes the conversations (parent questions and answers), the circulars and notices the school uploads, staff accounts, and billing records.
Which documents a school uploads is the school's decision and its responsibility. We do not inspect a document's content, and we do not stop it being uploaded.
What we can tell you is what follows. A document that names a child — an award list, a list of fee defaulters, a medical or disciplinary note — becomes part of the material answers are drawn from: those details can appear in an answer to a parent, and the document is visible to the staff who can see the conversation. If that is not the outcome you want, the decision not to upload it is yours to take.
We process whatever the school uploads, on its instruction, as its Data Processor — including a document that names a child.
The school obtains parental consent for a student's data when the student is admitted, and passes the data to eKTextAI on the school's instructions.
The admission-form clause is the school's mechanism. The Act also requires the school to serve an itemised notice alongside that consent — the data, the purpose, the rights route, how to withdraw, how to complain to the Board, the contact, and the language. That duty is the school's; we supply a template through the Data Processing Agreement. We do not take consent ourselves.
Parents who want to see, correct or delete their child's data, or to withdraw consent, contact their school; the school instructs us and we carry it out.
What we ask of the school, in writing. Before we process a school's data, and again with every bulk import, we hold the school's signed confirmation that it has taken parental consent and served the notice — naming the date, the notice version and the class of data. It sits with the Data Processing Agreement. It is evidence of the school's compliance, not a substitute for it.
When a parent or student uses eKTextAI, the conversation is visible to the school and to the staff the school authorises, so they can follow up. We also see it where we provide support.
The school tells parents this at onboarding and in its own notice, and decides which staff get access. We provide the roles and the log.
eKTextAI answers from the material your school gives it — your circulars, policies and notices — and tells the user when it cannot answer from that material rather than guessing. Some questions are handed to a person: a member of your school's staff. We provide the service to the school and we do not answer parents' questions ourselves.
An answer is not the school's official communication. Where the school's circular or notice says something different, the school's document is what applies.
We do not use children's data for tracking or behavioural monitoring, and we do not run targeted advertising to children or their parents based on it.
For the school: the exemption in the DPDP Rules 2025 (Fourth Schedule, Part A, item 3) covers an educational institution only for tracking or behavioural monitoring for its educational activities or for enrolled children's safety. It does not cover publishing a child's photo on a website or social media, or sharing children's data with a vendor for unrelated purposes.
We protect school, parent and student data with encryption in transit and at rest, role-based access controls, and regular backups.
If we become aware of a personal data breach affecting school data, we notify the school without delay and support the school's notification to affected parents and to the Data Protection Board.
School data is stored on servers in the European Union, operated for us by Contabo, with backups held there too. We do not currently run a server in India, and an Indian region is not scheduled. Moving the data does not reduce our obligations to your school: under the DPDP Act a transfer outside India is permitted unless the Government restricts it, and none is restricted today.
An account that is not used is blocked, and later deleted. A school that tells us it will not renew keeps its data to the end of the term it has paid for. We warn you before each step. If you want a copy of your data, ask us before the deletion date and we will send it to you. Signing in during the window brings the account straight back.
A sign-in by any of the school's authorised users, a question from a parent or end user, or a change an administrator makes. A school whose parents keep asking questions is using the service, even if nobody logs in.
While the subscription runs, nothing counts. A school with an active subscription and active message credits is not on this clock at all, whatever its staff or parents do or do not do.
| Point | What happens |
|---|---|
| Day 0 — the last sign-in or parent question; where the school has paid, the day the paid term ends | The starting date. Where the school has paid, the term-end notice is sent on this date. A free account has no notice on this date — its first is at day 30. |
| Day 30 | Email to the school's registered contact and last active administrator, with the dates below. |
| Day 40 | Reminder: blocked in 5 days; sign in or ask for a copy. |
| Day 45 | Account blocked. Request and reactivate routes both still work. Nothing is deleted. |
| While blocked | Signing in reactivates immediately, at no charge. |
| Day 75 | Reminder naming the erasure date. |
| 7 days before erasure | Final notice naming the exact date. |
| Day 105 — 60 days after the block | Data erased, confirmed in writing. |
Every notice is a plain email with its content in the body — never a link into a console the school cannot open.
Which day the clock starts on, for a school that pays. A school that tells us it will not renew keeps its data to the end of the term it has paid for; the 30/40/45/75-day sequence above then runs from that end date. A monthly school's term ends with the month it has paid for. Nothing is deleted while a term is paid for and running.
There is no downgrade to a smaller plan. If a school does not renew, we hold everything to the end of the term it has paid for, and from there the account is blocked at 45 days and the data erased 60 days later, with the notices above. It is not moved to the free plan, because a smaller plan cannot hold the records a larger one held.
The summer break — the clock is held. A school that tells us its closure dates has the clock paused for that period, so a quiet June does not block a school in July. The school asks in writing before the closure; we confirm the new dates in writing; the notices then use the new dates.
The copy is both a button and a request. The admin console has a self-serve export, and a school that would rather we do it can ask us in writing inside the window: we send it within 7 working days and confirm in writing. After deletion we cannot restore it.
Erasing during the term. The school can ask us to erase some or all of its data at any time, including mid-term. It is the school's data; we do it and confirm in writing. It is not a termination, it does not trigger a refund, and it cannot be undone — so we say what will be lost before we act.
The same clock runs from the end of the paid term: blocked at 45 days, erased 60 days later — day 105 — with the notices above. A school that wants its data sooner gets it sooner on written instruction; a school that wants it erased immediately gets that too, on instruction, except for the log and tax carve-outs above.
Our notices to the school are not notices to parents. Where the school's data is about to be erased, the school is the one that must tell parents — the 48-hour pre-erasure notice in Rule 8 of the DPDP Rules 2025 is the fiduciary's duty. We give the school the dates in time for it to do that.
We work to keep eKTextAI available at all times and aim for a high standard of uptime; we do not guarantee uninterrupted service.
As processor we do not decide the purposes of processing and do not take consent. Where the school has not instructed us — for example, using conversation data for our own product analytics or marketing — we will not do it.
For schools: Ranganath Shivaram, ranganath@marvelsoft.co.in, +91 95350 41234
For parents: your school is the first contact.
Read with: Privacy Notice · Terms of Service · Security