A fintech that touches your bank account and your payment schedules should be able to answer a simple question: what exactly do you hold about me?
Most fintech products bury the answer somewhere in a privacy policy that takes fifteen minutes to read and was written by a lawyer rather than the people who actually built the system. We want to do something different — give you a plain-English account of exactly what data AutoPay holds, why we hold it, what we deliberately never touch, and the architecture decisions we made to draw that line clearly.
This is not a legal document. It is a direct explanation from the people who built AutoPay about how we think about your data and why.
AutoPay is a scheduling and orchestration layer. We tell your bank when to move money and confirm that the instruction was executed. That is the entire job. Everything we store either directly enables that function or protects you while it happens.
If a piece of data does not help us schedule your payment, confirm it ran, or protect your account — we do not want it. Holding data we do not need creates risk we do not need to carry.
That principle is not just a value statement. It shapes actual engineering decisions: what fields we include in our database schema, what we ask Paystack to return after a transaction, what we log, and how long we retain anything.
Here is a complete table of the data AutoPay holds about you, why we hold it, and how long we keep it.
| Data | Why we hold it | Retention | Stored? |
|---|---|---|---|
| Name | Identify your account and personalise the app | Until account deletion | Yes |
| Email address | Login, payment notifications, and security alerts | Until account deletion | Yes |
| Phone number | Two-factor authentication and payment confirmation SMS | Until account deletion | Yes |
| Bank name & account number (linked account) | Required to initiate scheduled debits via Paystack Direct Debit | Until bank account unlinked or account deleted | Yes |
| Paystack authorisation code | Token Paystack issues after you complete the mandate setup — allows us to initiate future debits without you re-entering card or bank details each time | Until bank account unlinked | Yes |
| Payment schedules (recipient, amount, frequency, due dates) | Core product function — this is what AutoPay executes on your behalf | Until schedule deleted; history kept 24 months for your records | Yes |
| Payment execution history (timestamp, status, reference) | Lets you verify every debit, dispute anything unexpected, and gives us data to retry failed payments | 24 months rolling | Yes |
| Recipient account details (name, bank, account number) | Needed to execute transfers to the correct destination | Until recipient deleted from your list | Yes |
| Security PIN hash | Verifies your identity before every payment is authorised | Until PIN changed or account deleted | Yes — hash only, never raw PIN |
| Device & session tokens | Keeps you logged in and allows us to detect suspicious login attempts from new devices | 30 days from last activity | Yes |
| App activity logs | Helps us debug errors, investigate failed payments, and improve reliability | 90 days | Yes — anonymised after 14 days |
This list matters as much as the one above. These are active decisions — things we could theoretically store but have chosen not to, because holding them would create risk without adding value to the product.
| Data | Why we do not hold it | Stored? |
|---|---|---|
| Your bank login credentials (username & password) | AutoPay never requests your internet banking password. We use Paystack Direct Debit mandates — you authorise a debit instruction directly with your bank. We never see or store your login details. | Never |
| Full card number (PAN) | Paystack handles card tokenisation. We only store the auth code they return — a reference token, not the card number itself. The raw PAN never touches our servers. | Never |
| Card CVV / expiry | Same reason as above — Paystack processes and holds this. We do not and cannot access it. | Never |
| Account balance or transaction history from your bank | AutoPay does not read your bank account. We do not use open banking APIs to retrieve your balance, statement, or spending history. We only instruct outgoing debits — we cannot see what else is in your account. | Never |
| Your raw 4-digit PIN | When you set your security PIN, we run it through a one-way hash function immediately. We store only the hash. Even we cannot reverse it to see what your PIN is. | Never — hash only |
| Location data | AutoPay does not request or store your GPS location. There is no product reason to know where you are when you schedule a payment. | Never |
| Contacts, photos, or other device data | We do not request access to your phone contacts, camera roll, microphone, or any device data beyond what is necessary to run the app itself. | Never |
| Behavioural or advertising data | AutoPay does not use advertising SDKs, does not track cross-app behaviour, and does not sell or share your data with third-party advertisers. There are no ads in AutoPay. | Never |
Saying "we do not store X" is easy. The harder question is: how does the system make it structurally impossible to store X, rather than relying on good intentions?
Here is how the payment flow actually works:
This is the most sensitive thing we store and the one worth explaining in detail. When you link your bank account, Paystack processes the setup and issues an authorisation code. This is a reference token — not your card number, not your bank password. It is essentially a key that tells Paystack "this customer has already given permission for debits up to this mandate limit."
We store this token encrypted in our database. Without access to both the token and our encryption keys, it is not usable. Paystack also allows you to revoke it directly from their end — if you delete your bank link in AutoPay, we delete our copy of the token and notify Paystack to deactivate it.
Some people assume that because AutoPay can debit your account, it can also read it. This is not how Paystack Direct Debit works. The authorisation we hold is a one-directional instruction: it allows a debit of a specified amount. It does not grant any read access to your account — not your balance, not your transaction history, not your standing orders with other institutions.
Think of the authorisation code as a standing cheque that Paystack holds. It tells the bank to pay a specific amount when presented. It does not give anyone access to your account statement. That is the design of Direct Debit — it is deliberately narrow.
We use a small number of third-party services to run AutoPay. Here is an honest account of what each one can see:
That is the full list. We do not share your data with data brokers, analytics companies, or any third party for advertising purposes. We do not sell data. We do not monetise your payment behaviour.
Like all businesses operating in Nigeria, we will comply with a lawful order from a competent authority — such as a valid court order — if required by law to disclose specific data. We will notify you if legally permitted to do so.
When you request account deletion, here is the exact sequence:
This post is not a substitute for our full privacy policy, which is a legal document that covers edge cases and specific regulatory language. But this post is the honest account of how we actually think about your data — written by the people who made the decisions, not by a compliance template.
If you have a question about something specific that is not covered here, email us. We will answer directly.
AutoPay holds only what is needed to schedule your payments and confirm they ran. Nothing else. Try the beta and see exactly what the app asks for — and what it does not.
Try the Beta App →