The Difference Between an App That Shows You Your Money and One That Moves It

The line, and why it is not a spectrum

Financial products get described on a scale from cautious to powerful, as though there were a smooth gradient between a budgeting app and something that pays your bills. There is not. There is a discrete step, and it happens at the moment a product acquires the ability to cause an irreversible thing to happen.

Before that step, the worst outcome from a defect is a wrong number on a screen. You look at it, you disagree with it, you carry on. After it, the worst outcome from the same defect is a payment that went somewhere it should not have, at a time you did not choose, in an amount you did not intend — and unwinding that involves your bank, possibly the recipient, and time you were not planning to spend.

The step is not about how much money is involved or how sophisticated the product is. A tool that moves £20 has crossed it. A tool that models your entire retirement has not.

What actually goes wrong on each side

It is worth being concrete, because abstract risk talk lets everyone off the hook.

Notice that the failure on the showing side is not harmless. A budgeting app that quietly omits an account will tell you that you have more room than you do, and that has consequences. The difference is that you remain the thing that acts, so there is a human checkpoint between the defect and the damage. Removing that checkpoint is precisely what “automation” means, and it is what should be argued for rather than assumed.

Guidance and action are different products

The temptation, having built something that understands a person’s finances well, is to let it act on that understanding. It looks like the obvious next step and it is where a lot of product roadmaps are pointing. Two things are worth saying about it honestly.

The first is that the case for it is real. Most people do not fail at money because they lack information. They fail at execution — the transfer they meant to make, the subscription they meant to cancel, the overpayment they meant to set up. A tool that closed that gap would be genuinely valuable, and pretending otherwise would be posturing.

The second is that closing that gap changes what the product is, and therefore what has to be true about it. A guidance product needs to be right often enough to be useful. An action product needs to be right essentially always, needs to fail safely when it is not, needs an audit trail, needs a way to undo, and needs somebody accountable when undoing is not possible. Those are much harder problems, and they are not solved by the product being good at the guidance part.

Where earmarkIQ sits today

Writing this while building in the space obliges us to be exact about our own position rather than gesturing at principles.

earmarkIQ is on the showing side. Bank connections run under Account Information Services — a read permission — through Finexer Ltd (FRN 925695), an FCA-authorised provider, with earmarkIQ as an Appointed Representative. earmarkIQ reads balances and transactions, categorises them, tracks subscriptions and property equity, and builds a payday allocation. It cannot move money, because AIS does not permit it to. That is not a setting we chose; it is the permission the product runs on.

The assistant connection is also on the showing side. earmarkIQ Context is a read-only MCP server. An assistant connected through it can read your categorised picture and nothing else, because nothing else exists in it — there is no mutating capability, and a test in our build fails if one is ever added. Every access is recorded and you can revoke it yourself at any moment. Claude is verified; other MCP-capable assistants can connect the same way, though we have not verified each individually.

Where payment initiation would sit, if it is ever enabled

The honest disclosure is that payment initiation is within the permissions earmarkIQ operates under, and on the roadmap. It is currently disabled. We would rather say that than let anyone discover it later and wonder what else was unsaid.

So it is worth setting out now what it would and would not be, because the commitment is more meaningful made in advance:

• You would start it. A payment would begin with you deciding to make one — never with the app, a model, or an assistant concluding that one should happen.
• You would confirm the specifics. The exact amount and the exact payee, shown to you, before anything is sent.
• Your bank would authenticate you. Every payment, individually, on your bank’s own screen. That is how Payment Initiation Services works and it is not something a provider can design around.
• It would not be a standing power. No ability to pay later, pay again, or pay something else.
• No assistant would be able to trigger it. Context is read-only and would stay read-only. The two things would not be joined up.

In other words, even with PIS enabled, earmarkIQ would remain on the showing side of the line in the sense that matters: the decision would stay with you, and the confirmation would stay at your bank. What would change is that executing a decision you had already made would take fewer steps. That is a smaller and more defensible claim than “an app that manages your money for you”, and it is deliberately the one we are making.

Questions worth asking any provider

If you take one thing from this, make it these five questions. They work on us as well as on anyone else.

1. Which Open Banking permissions do you hold, AIS, PIS, or both? This is a matter of public record on the FCA register, so a vague answer is itself informative.
2. Can anything in the product cause money to move without me confirming that specific payment? The only reassuring answer is no.
3. If read-only is claimed, how is it enforced? A policy can change; an absent capability cannot be invoked. Ask which you are relying on.
4. What can I see afterwards? An audit trail of what was accessed, visible to you, beats any assurance.
5. How do I revoke, and how fast does it take effect? It should be immediate, self-service, and not require an email to support.

The background on permissions is in what UK apps can and cannot do with your data, and the assistant-specific version of the same reasoning is in should you connect your bank account to an AI assistant?.

Frequently asked questions

Read next