A permission engine for money that something else spends.

Section 01Status of this document

Version 2 of this paper was a marketing document. It described an ambition as though it were a product, carried claims it could not support, and asked the reader to take a great deal on trust. This version is written for people who will check.

Commercial detail, including the raise, use of funds, unit economics and projections, is not in this document. It is in a separate confidential investor deck available on request from adam@rdbnk.com.

Section 02The problem

Software has learned to shop. It has not learned to be trusted with money, and the industry knows it.

Through 2025 and 2026 the payments industry built rails for autonomous spending. Mastercard launched Agent Pay. Google published the Agent Payments Protocol with a large partner group. Visa began tokenisation for agent-initiated purchasing. Stripe previewed machine payments. The x402 extension shipped for stablecoin settlement. Fiserv released an agentic operating system to banks.

A gap remains in the middle of all of it, and it has a name: Know Your Agent. Every serious framework converges on the same four requirements.

• Verifiable identity. Which agent is acting, and on whose authority.
• Auditable authority. A record of what the human actually authorised, not what the agent inferred.
• Real-time revocation. The ability to stop it mid-flight, not at the next statement.
• Assigned liability. A named party who carries the loss when it goes wrong.

That is a parental controls specification. The capability agentic commerce is missing is the capability a bank for young people has to build in order to exist at all.

The consumer problem underneath it

Separately, and more immediately, a specific group of people is badly served by existing accounts: young adults who move money across currencies, who transact constantly in small amounts, and who spend a meaningful part of their week on administration a competent assistant could absorb. Booking, comparing, chasing, rebooking, splitting, remembering.

Existing products solve one half or the other. Multi-currency wallets move money well and do nothing else. Assistants can plan a trip and cannot pay for it. Nobody has built the connective layer, because the connective layer is the part that is dangerous.

Section 03Market sizing

Every figure in this section is sourced, and where a number is our own estimate it is labelled as such. Figures we cannot source have been removed.

Total addressable market

The realistic long-run market is consumer current accounts and wallets for people aged 18 to 35 in the UK and EU, plus the emerging market for delegated-authority payment controls. We do not have a defensible single number for the second and will not invent one.

Serviceable market at launch

The UK launch cohort is people aged sixteen and over with genuine cross-border money movement, weighted towards students and early-career workers. The clearest measurable population inside that is international students.

Sources: HESA, Higher Education Student Statistics UK 2024/25, published 27 January 2026. House of Commons Library briefing CBP-7976.

International student numbers fell 6.1% year on year, the second consecutive annual decline, driven largely by visa policy. We note this because it cuts against us. The cohort is real and large, but it is not growing, and a plan that assumes tailwind here would be wrong.

Obtainable market

Our own estimate, not a sourced figure: a credible pilot is 1,000 activated users in year one, and a defensible Series A case is roughly 25,000 activated users in the UK cohort. Those numbers are targets to be tested, not projections.

The gaming figure, corrected

Sources: Newzoo Global Games Market Report 2025; Newzoo quarterly update reported June 2026.

Section 04Competitive landscape

Version 2 claimed no bank is built as a community and framed youth accounts as basic holding products. That was too absolute and it invited an easy rebuttal. Rumba enters a populated market and will be compared feature by feature.

Where we are genuinely weaker

• Every named competitor holds a licence. We hold none.
• Revolut and Monzo have distribution measured in millions and a marginal acquisition cost close to zero through referral.
• GoHenry and the incumbent under-18 products are cheap or bundled free as a retention hook, which makes youth accounts a hard market to charge for.
• Any of them could ship an assistant faster than we can obtain permissions.

Where the difference is real

Incumbent limits are configuration inside an app. What we are describing is a policy service that sits outside the application and outside the model, where every rule is a signed, versioned, revocable object and every decision is logged in a form that could be handed to a regulator. That is difficult to retrofit into a product where the rules live as database flags, and it is the only part of this business that is not purchasable.

Our bet is that incumbents will optimise an assistant for engagement, and that the winning product for money is optimised for provable restraint. We may be wrong about that. It is the central strategic assumption of the company and it is stated here so it can be argued with.

Section 05Launch wedge

One country, one cohort, one product. Everything else is roadmap.

Version 2 described a product for teenagers, young adults, gamers, musicians, athletes, creators, entrepreneurs and parents, across two countries, with a marketplace, a community, an education platform, credit, lounges and a future digital asset. Each of those is difficult and several are separately regulated. Attempting them together is the most likely way this fails.

The three tiers

Sixteen is a meaningful line in the UK. It is the age at which a person can generally hold a payment account in their own name rather than as a beneficiary of an adult's account, which removes an entire parent-controlled product from the launch build.

What is still deferred

Junior accounts for members aged thirteen to fifteen. The member marketplace. In-app chat. Console and storefront integration. Lounge access. Any tradeable digital asset. Each is a separate regulated or moderation problem and none is needed to prove the core idea works.

Section 06The product at launch

Nothing in the right-hand column says "available". That is accurate and we would rather it read that way than imply otherwise.

Section 07The permission engine

This is the product. Everything else in this paper is a way of getting it into people's hands.

Three layers, deliberately separated

• The assistant. Conversation, research, comparison, form filling, preparation. It can propose a payment intent. It has no write access to the ledger and no ability to authorise anything.
• The policy engine. Deterministic, outside the model, not written in natural language and not persuadable. It evaluates every proposed action against the mandate and returns allow, require approval, or deny.
• The regulated layer. Balance, screening, authentication and settlement, operated by the licensed partner. It is the only thing that moves money.

The mandate

A mandate is a signed, versioned object created by the customer. It specifies the funding account, permitted categories, permitted merchants, a threshold below which actions execute without interruption, a band requiring explicit approval, an absolute ceiling, and velocity caps. It can be amended or revoked instantly, and every version is retained.

What the engine must record

For every action: what the customer asked for, what the assistant found and when, what it proposed, which mandate version was evaluated, what the engine decided and why, what the customer approved, what authentication occurred, what was charged and to whom. Retained in a form that can be reconstructed for a dispute or a regulator.

Section 08Assistant threat model

Keeping the model away from the ledger is necessary and nowhere near sufficient. An assistant can create liability long before money moves.

Regulated activities the assistant will not touch

Insurance distribution is regulated. An earlier demonstration offered travel insurance as a casual add-on with no provider, eligibility, exclusions or demands-and-needs process. It has been removed and will not return until counsel and a licensed partner have approved the journey. The same applies to credit, investment products and currency services beyond the scope of the sponsor's permissions.

Section 09Rewards and liability

Version 2 described points earned on peer-to-peer transfers and on how long they were held, with a fixed value that was never stated, funded from a source that was never named. Each of those is a problem and together they are a serious one.

Why this matters more than it sounds

A reward programme is a promise to hand over value later. Every unredeemed point is a debt. Programmes that issue points faster than the commission funding them arrives are borrowing from their own future, and the failure shows up as devaluation, which lands on the customers who trusted the programme most. Constraining issuance to earned commission means we cannot run away from ourselves.

Anti-gaming controls

• Earning limited to card spend at contracted merchants. No earning on transfers, top-ups, cash or currency exchange.
• Points issued after settlement, not authorisation, and clawed back on refund or chargeback.
• Per-customer and per-merchant velocity caps.
• Redemption floor to prevent nuisance-value churn.
• Full terms published before launch, changes notified in advance, never retrospective.

No merchant network is contracted. Building it is the main commercial task before launch, and until it exists the reward programme cannot operate.

Section 10Security architecture

Principles

• The model is never trusted. It cannot write to the ledger, amend a mandate, or authorise a payment. Compromising it should yield an unhelpful assistant, not a loss.
• Deny by default. Categories, merchants and payees are allowlisted. Anything unrecognised stops and asks.
• Separation of duties. Proposing, authorising and executing are three different systems.
• Everything is logged. An action that cannot be reconstructed afterwards should not have been possible.
• Revocation is instant. A customer can suspend all assistant authority immediately, from anywhere in the app.

Current public site

The website is a static build with no database, no login and no payment processing. It carries HTTPS, a content security policy, a referrer policy, framing protection and no third-party analytics or advertising. A responsible disclosure process is published at rdbnk.com/legal.html and in security.txt.

Known gaps, being addressed

• Transport security, content type and permissions headers are not yet set at the server, only where meta tags allow.
• DNSSEC and CAA records are not yet published.
• DMARC is not yet configured and SPF uses a soft-fail policy.
• Typefaces are served by a third party, which discloses visitor network data. Self-hosting is planned.

Independent penetration testing and a formal threat assessment will be completed before any regulated service launches, not after.

Section 11Regulatory position

Rumba is unauthorised and carries out no regulated activity. This section describes how that changes, and what has to be true before it does.

The route

1. Phase one, agent or distributor of a licensed e-money institution. The sponsor holds the permissions, issues the e-money and safeguards customer funds. Rumba builds the experience and the permission engine. This is the phase currently being funded.
2. Phase two, own authorisation. Applying in our own right, separately capitalised, and not funded by phase one. Presenting these as a single step would misrepresent both the cost and the timeline.
3. Phase three, expansion. Additional jurisdictions and the Junior tier, each with its own approval and its own safeguarding model.

Section 12Data protection and young people

An assistant of this kind touches unusually sensitive material: voice, calendar, contacts, location, purchase history and inferred behaviour. That demands more care than a normal current account, not less.

• Purpose limitation. Data gathered to complete a task is used for that task. It is not repurposed into advertising or profiling.
• No training on customer data. Conversations, transactions and calendar contents will not be used to train models, by us or by a supplier. This will be contractual, not aspirational.
• Granular consent. Calendar, contacts and location are separate permissions, each refusable, each revocable, and the product remains usable without them.
• Voice. Where browser or device speech recognition is used, the customer is told plainly that audio may reach the browser or device vendor. Current disclosure is at legal.html.
• Retention. Action logs are retained as long as regulation requires for disputes and audit, and no longer. Conversational content is retained on a shorter schedule.
• Export and deletion. Available on request, subject only to records we are legally obliged to keep.

Members under eighteen

Because the account opens at sixteen, some members are minors from day one. The following applies to every member under eighteen and is part of the launch build, not a later addition:

• Age assurance proportionate to the risk of the product, at onboarding.
• Defaults set to the most protective option, and changing them is a deliberate act.
• No behavioural advertising and no profiling for marketing.
• No engagement mechanics designed to increase spending or session time.
• Data collection minimised beyond the adult standard, with location and contacts off by default.
• Credit and any digital asset product unavailable and not marketed.
• Clear, obvious reporting and support routes, and staff trained to recognise a safeguarding concern.

The Junior tier, later

For members aged thirteen to fifteen the requirements go further: the parent or guardian is the account holder, consent must be verified rather than asserted, and a full safeguarding operating model with trained staff and escalation is needed. None of that exists today, which is why the Junior tier is a later release rather than part of the launch.

Section 13Governance

Current state, stated plainly

• One founder acting as Acting CEO, and one executive board member with a declared conflict.
• No independent directors. No compliance officer, MLRO, risk lead, general counsel or CISO.
• No audit or risk committee, because there is no entity to constitute them in.

Combining operations and cyber security in a single COO role, as version 2 proposed, was a mistake and has been separated. A regulated payments business needs an accountable security owner distinct from the person running operations.

Priorities, in order

1. Incorporate, and appoint regulatory counsel.
2. Recruit an experienced regulated-payments chief executive. The founder holds Acting CEO precisely so this is not an awkward conversation later.
3. Appoint independent directors, before any related-party contract.
4. Appoint compliance and MLRO capability, part-time initially.
5. Separate security accountability from operations.

Section 14Roadmap and dependencies

Months are from the close of the current funding phase. Each milestone lists what must be true first, because a roadmap without dependencies is a wish list.

Month six is a stop point. If no sponsor term sheet is signed by then, the correct decision is to stop and return remaining capital rather than build a product that cannot legally operate.

Section 15Risk register

Section 16Sustainability

Rumba intends to direct a defined portion of net revenue to clean water work in Ghana. The founder has supported causes in West Africa since childhood and has met senior figures there who are supportive of the initiative.

Those are relationships and encouragement. They are not funding commitments, formal endorsements or delivery agreements, and version 2 of this paper allowed them to read as more than they were.

The context is real

Illegal small-scale mining in Ghana, known locally as galamsey, has polluted major water bodies and taken agricultural land, and the Water Research Institute has warned about the consequences for Ghana's water supply. That problem does not depend on us for its seriousness.

What is not settled

• The named delivery partner and the due diligence performed on them.
• The exact allocation formula, expressed as a percentage of a defined revenue line.
• Governance: who authorises payments, who verifies delivery, who audits.
• Measurable outcomes, and how they are reported.

Until those are agreed we will describe this as an intention. The allocation will be funded from net revenue as a defined cost line, not from unredeemed customer rewards, for the reasons set out in section 09.

Section 17Team

Vacant, and material

Chief executive with regulated payments experience. Independent non-executive directors. Compliance officer and MLRO. Risk lead. Chief information security officer, separate from operations. General counsel. Product leadership. None of these roles is filled, and the business is not viable until several of them are.

Section 18What we have not proven

This section exists because a paper that only argues one side is not worth reading.

• That anyone will switch. We have conducted no structured customer research. Zero interviews with the launch cohort. We do not know whether the assistant is a reason to change accounts or merely a pleasant feature.
• That anyone will pay. Willingness to pay a monthly subscription for an assistant is assumed, not tested.
• That a sponsor will work with us. No conversation has reached term sheet.
• That the engine is buildable to the standard described. It is not novel computer science, but it is unbuilt.
• That the assistant is economical. Inference cost per active customer is our least certain assumption and rises with the engagement we are trying to create.
• That merchants will fund rewards. Merchant-funded rewards require negotiating leverage that a pre-launch business does not have.
• That incumbents will move slowly. The core strategic bet, stated in section 04, and entirely arguable.
• That the brand works. No testing with the target cohort has been done.

A reader who concludes from this section that Rumba is early is reading it correctly. The purpose of the current phase is to convert several of these unknowns into evidence.

Section 19References

• HESA, Higher Education Student Statistics: UK, 2024/25, published 27 January 2026 - hesa.ac.uk
• HESA, Where students come from and go to study, 2024/25 - hesa.ac.uk
• House of Commons Library, International students in UK higher education, briefing CBP-7976 - commonslibrary.parliament.uk
• British Council, New data releases from UCAS and HESA, February 2026 - britishcouncil.org
• Newzoo, Global Games Market Report 2025, $188.8bn forecast, and the June 2026 quarterly update reporting $201.6bn for 2025 - reported at gamesbeat.com
• Mbanq, banking-as-a-service platform - mbanq.com
• HUG Recruitment, preferred talent partner - hugrecruitment.com
• Rumba privacy, terms and security disclosures - rdbnk.com/legal.html

Statements in section 02 about Mastercard Agent Pay, Google's Agent Payments Protocol, Visa tokenisation, x402 and Fiserv agentOS are drawn from those organisations' public announcements during 2025 and 2026. They are included as market context. We have no relationship with any of them.

Section 20Disclaimer