What we are launching with

Money, your bank, and the e-wallet.

We never see your bank login and we never hold your money. A licensed payment company does both. Here is exactly where the money sits and exactly what has to be true before any of it moves.

What this part does

It moves money from you to your child's savings balance when the work in the family agreement is done. We call that balance the e-wallet. It is a running total, like a bank statement, not a pile of cash sitting somewhere.

Read this before anything else

GuardNIL is not a bank. Your money is held by Stripe, a licensed payment company. Your balance is not insured by the government the way a bank account is. We say this on our footer, our compliance pages, and here.

Linking your bank, step by step

1
You press the link button.
A window opens. That window belongs to Stripe, not to us. It runs on Stripe's systems.
2
You sign in to your bank inside Stripe's window.
Your bank username and password never touch GuardNIL. We cannot read them, we do not receive them, and there is nowhere in our database they could be stored. The technical name for this is Stripe Financial Connections.
3
Stripe tells us the link worked.
Our server then asks Stripe directly to confirm it, instead of trusting the message that came back through the browser. If the confirmation says the link belongs to a different person, we refuse it.
4
We save four small things.
The last four digits, the bank name, a reference number that is meaningless outside Stripe, and a yes or no for whether it is verified. That is the whole record.

If you replace your bank

We tell Stripe to release the old one at the same time we save the new one, so an old link is not left connected in the background. Each parent has one funding source at a time.

You can skip this

You can finish setup without linking a bank. Payments stay paused until you come back and do it.

How a payment is approved

Nothing pays out on its own. A parent has to approve it, and then our server checks the whole thing again by itself before anything moves.

1
You press Approve.
This sends a request to our server. It does not move any money.
2
The server checks you are signed in.
An unsigned request is refused.
3
The server checks this payment belongs to you.
It looks up the payment and confirms your account is the parent on it. You cannot approve someone else's payment even if you know its number.
4
The server checks the payment is still waiting.
A payment that already went through cannot go through twice.
5
The server checks you are the primary parent.
A second parent with look-only access is refused here.
6
The server checks every part of the agreement is done.
If any part is unfinished, the request is refused with the message "All incentives must be completed before approving." This is the important one, and the next section explains what it does and does not mean.
7
The server claims the payment before calling Stripe.
It marks the payment as taken in a single database step that only succeeds once. If you press Approve twice quickly, or two parents press it at the same moment, the second one is told "This payment was already processed."
8
Stripe is called with a one-time key.
The key means Stripe will not run the same transfer twice even if our request reaches them twice. If Stripe fails, the payment is put back to waiting rather than left half done.
9
The balance is written.
A new line is added to the e-wallet ledger. If that write fails, the payment is put back to waiting.

Why the button is not the gate

This is the single most important security idea in the money part of the app, so we will say it slowly.

The Approve button on your screen is decoration. A person who knows how websites work can change what a button does, or skip the page entirely and send a request straight to our server. So we assume they will.

Every check listed above runs on our server, after the request arrives, no matter how it arrived. Turning the button green in a browser gets you nothing. This is what people mean when they say a system is authoritative on the backend.

Two honest notes about the checks

Finishing one pillar does not release its share. Some of our older material described the money as unlocking piece by piece as your child finishes each pillar. It does not. Every enabled part of the agreement has to be finished before the whole payment can be approved. It is all or nothing.

The approval step does not check that your bank is verified. It checks who you are, whether the payment is yours, and whether the work is done. It does not re-check the bank link. If no destination is set up, the balance is still recorded and no real money moves. We would rather you hear that from us.

The e-wallet ledger

The e-wallet is a list of lines. Money in, money out. The balance is the lines added up. There is no separate balance number that could drift away from the lines.

Lines cannot be edited. The permission to change a ledger line was removed from the database. It is not that we choose not to. There is no rule that allows it.
Lines cannot be deleted. Same thing. The permission does not exist.
A repeated transfer cannot create two lines. The database refuses a second line for the same transfer.
Taking money out is done in one locked step. The database locks the ledger, works out the balance, refuses if there is not enough or if a request is already pending, and writes the request. All of it happens together or none of it does. We built this after we found that two requests sent at the same instant could both pass the check.

What data this part touches

What
Your bank username and password
Who holds it
Nobody but your bank
Notes
Never reaches Stripe's record either. You type it into your bank's own screen.
What
Your full account and routing numbers
Who holds it
Stripe
Notes
Never in our database. There is no column for them.
What
Your card number, if you use a card
Who holds it
Stripe
Notes
Same. We never see it.
What
Last four digits and bank name
Who holds it
GuardNIL
Notes
So you can tell which account is linked.
What
A verified yes or no
Who holds it
GuardNIL
Notes
True only when Stripe says the setup finished.
What
Every e-wallet line
Who holds it
GuardNIL
Notes
Cannot be edited or deleted by anyone.
What
Every approval and refusal
Who holds it
GuardNIL
Notes
Written to a permanent record with who did it and when.

Money data: what we hold and what Stripe holds
What	Who holds it	Notes
Your bank username and password	Nobody but your bank	Never reaches Stripe's record either. You type it into your bank's own screen.
Your full account and routing numbers	Stripe	Never in our database. There is no column for them.
Your card number, if you use a card	Stripe	Same. We never see it.
Last four digits and bank name	GuardNIL	So you can tell which account is linked.
A verified yes or no	GuardNIL	True only when Stripe says the setup finished.
Every e-wallet line	GuardNIL	Cannot be edited or deleted by anyone.
Every approval and refusal	GuardNIL	Written to a permanent record with who did it and when.

What a parent sees

A countdown to the next payment.
The current e-wallet balance.
A list of payments waiting for approval, with what is done and what is not.
A history of payments that already went through.
Which bank is linked, shown as the bank name and the last four digits.

If something goes wrong

Stripe is down when you approve

The payment goes back to waiting. It does not get stuck halfway. You try again later.

You press Approve twice

The second press is refused with a clear message. Only one transfer can ever exist for one approval, because Stripe is given a key that makes a repeat impossible on their side too.

Someone disputes a charge

Stripe tells us. Our server checks the message really came from Stripe before it believes it. For a dispute on a children's privacy permission charge, we mark that permission as withdrawn and write a permanent record of it.

Stripe sends the same message twice

We write down the message number the first time. A repeat is recognised and ignored. Nothing happens twice.

You want your money out

You request a withdrawal. The locked single-step check described above runs. If the balance is not there, or a request is already pending, it is refused rather than queued.