What the AI workforce is.
Fluxa runs five named AI agents that handle operational work on every merchant account: drafting support replies, parsing onboarding documents, watching platform health, verifying every fee, tracking regulatory change. They are not autonomous decision-makers. Every consequential output, defined as anything with a financial, legal or reputational effect, is reviewed and sent by a named human at Fluxa before it leaves.
This means a smaller team can run a payments business at a higher cadence without dropping the standard. It does not mean replacing humans in the loop. KYB approvals, dispute resolution, complaints handling, press statements, anything affecting a merchant’s ability to take payments. These are all human-decided, against the same documented criteria a fully manual team would use.
This page covers what each agent does, where the human boundary sits, which models and providers we use, how data is handled, and the regulatory frameworks we built against. It is reviewed quarterly. The agents and their boundaries are documented in the codebase, not just on this page; every escalation, every approval, every drafted-but-not-sent message is logged.
The five agents.
Each agent has a defined scope, a named human who reviews its output, and an explicit list of actions it cannot take alone. The five names below are the same as those on the homepage. The agents are operational labels used in our codebase and audit trail; they are not personas presented to customers as human staff.
Tom Harris
Operations & Support
Live · 24/7
- Drafts replies to support tickets in your tone of voice
- Traces any payment across every state and retry
- Drafts chargeback rebuttals end-to-end
- Spots a 3% decline jump and names the cause
- Reads webhook logs and tells you what broke
Cannot do alone
Money decisions, ledger writes, custom merchant terms, financial impact above £100, KYB or AML. Human operator approves every send.
James Carter
Onboarding
In testing · Mon-Sat
- Pulls KYB straight from Companies House
- Runs PEP, AML and sanctions checks instantly
- Writes API examples for your exact stack
- Reviews your first ten test charges
- Cuts onboarding from weeks to days
Cannot do alone
Approve an onboarding. KYB decisions made by Fluxa against MLR 2017, with the human reviewer named on the decision record. Human operator signs off.
Sentinel
Platform Health
Live
- Watches every transaction every minute
- Catches decline climbs before customers notice
- Spots latency spikes before alarms trip
- Self-heals what does not need a human
- Pages a human only when it matters
Cannot do alone
Anything risky. Account freeze, fund hold, scheme dispute response, anything outside documented self-heal playbooks. Human operator reviews.
Auditor
Revenue Integrity
Live
- Verifies every fee against your signed contract
- Reconciles settlement to the penny every night
- Catches pricing drift the day it lands
- Audits your refund and chargeback ledger
- Reports any payments partner overcharge inside 24 hours
Cannot do alone
Material refunds, scheme credit adjustments, ledger corrections. Anything that moves money. Human operator confirms.
Compliance
Regulatory Cover
Live
- Tracks every FCA and AML rule change daily
- Reads new regulations the day they ship
- Spots AML signals across the dashboard
- Files documents before the regulator asks
- Keeps your monitoring inspection-ready
Cannot do alone
SAR submission, regulator communication, anything carrying a personal accountability signature. Human operator authorises.
Human-in-the-loop boundaries.
The rule is explicit and documented in code: any action with a financial, legal or reputational effect on a person or business is reviewed and approved by a named human before execution. This is not a fallback; it is the default path for any non-trivial output.
Mandatory escalation triggers
The agent stops drafting and routes to a human if any of the following are present: a custom merchant term is requested; a financial impact above £100 is implied; a KYB or AML question is raised; a complaint is mentioned; a regulator, journalist, or named public figure is referenced; the merchant requests an account closure or fund release; the message touches an open dispute. These triggers are listed in the codebase and unit-tested.
No silent autonomous action
No agent can independently send an email, post to social, modify a ledger entry, change a merchant’s account state, approve a KYB, release reserves, or pay out settlement. Every action of this kind is gated behind a human approval click logged with the reviewer’s identity, timestamp, the agent’s draft and reasoning, and the final action taken.
Approval is not formality
The human reviewer is expected to read the draft, check the source material the agent cited, and confirm or correct the output. CJEU SCHUFA (C-634/21) made clear that a tick-box human signature does not satisfy meaningful human involvement under GDPR Article 22. The Fluxa approval flow shows the original message, the agent’s draft, the cited sources, and a free-text reason field for any edits the human makes.
Fail closed
If the agent encounters a query it cannot ground in retrieved sources with sufficient confidence, it does not generate a best-guess answer. It routes the case to a human with a note explaining the gap. The default failure mode is human review, not hallucination.
Transparency and disclosure.
Under EU AI Act Article 50, AI systems that interact with natural persons must disclose that fact unless it is obvious from context. Fluxa applies the disclosure even where the context already makes it clear.
Every AI-drafted message is signed by a human
Replies drafted by Tom are sent under the name of the Fluxa team member who reviewed them. The reviewer is identifiable, contactable and accountable. The agent is not presented as a person.
This page is the public disclosure
Fluxa publishes the existence, scope and limits of each agent on this page. New agents or material expansion of an existing agent’s scope are announced on the changelog before they go live. Merchants can ask which messages were drafted by an agent at any time and receive a written answer with the log entry.
No deceptive impersonation
No Fluxa agent is given a human-presenting identity, a stock photo, a fake job title, or a personal LinkedIn profile. The five agent names (Tom, James, Sentinel, Auditor, Compliance) are operational labels documented as such. The founder/team profiles on /about are real people with real photos.
Synthetic content marked at source
Any AI-generated content published externally (social posts, generated graphics) carries provenance metadata where the platform supports it (IPTC media credentials, C2PA where the channel implements it). Where it does not, the changelog records what was AI-drafted and when.
Models and providers.
Fluxa uses general-purpose large language models as drafting assistants. The choice of model and provider is published; changes are logged on the changelog. No model output is treated as a decision; it is treated as a draft that a human then approves, edits, or rejects.
Provider relationship
Fluxa uses mainstream large-language-model providers under their published API terms. The controlling clause is the default API position: prompts and completions are not used to train provider models. The current provider list is documented in the codebase; material changes are released-noted on the changelog. As the AI workforce expands or our merchant base reaches the threshold for Article 13 of the EU AI Act, we will move to enterprise contracts that include audit-rights and incident-reporting clauses formally.
Model selection
Different agents use different models based on the task. Document parsing uses a model with strong structured-extraction performance; drafting uses a conversational model with strong instruction-following; classification uses a smaller, faster model. The current model assignment per agent is documented in the codebase; changes are released-noted.
Prompt versioning
Every prompt used by every agent is versioned in the codebase. Changes are reviewed via the same pull-request process as any other code. The prompt history for any drafted output is traceable: which version of which prompt produced this draft, on which date, with which inputs.
Provider failover
If a provider is unavailable or returns an error, the agent does not silently swap models or paper over the gap. The case is routed to a human with a note. We do not run a multi-vendor blend that obscures which model produced which output, because that would make the audit trail unusable.
Data, privacy and retention.
Personal data sent to a model provider is a regulated activity. Fluxa is the controller; the model provider is a processor under GDPR. The Data Processing Addendum signed with each provider is on file, and a Data Protection Impact Assessment is maintained.
What gets sent to a model
The minimum necessary. A support ticket and the relevant merchant account context, redacted of unrelated personal data. A KYB document and the extraction schema. A draft brief and the public Fluxa knowledge base. We do not send full customer databases, transaction histories beyond the current case, or unrelated merchants’ data into a prompt context.
What never gets sent
Card numbers, CVVs, full card data: handled entirely by the PCI-DSS scope at the gateway, never enter the AI workforce stack. Bank account numbers and sort codes are tokenised before any model call. Authentication credentials, API keys, internal secrets: programmatically stripped from prompt context before send.
No training on customer data
Every provider contract is on the no-training tier. Prompts and completions are not retained by the provider for model improvement. This is the controlling clause for our use of these providers; if a provider changes terms, we either renegotiate or move.
Retention
Agent drafts, source inputs, and the human-reviewer decision are retained for seven years as part of the operational audit trail (in line with FCA record-keeping expectations for regulated firms; Fluxa is not directly authorised but follows the equivalent retention standard via its payments partner). Personal data is purged on data-subject erasure requests in line with GDPR Article 17, except where retention is required by law.
Data Protection Impact Assessment
A DPIA covering each agent’s data flows is maintained, reviewed quarterly, and available on request to a supervisory authority. The DPIA names the personal-data categories processed, the lawful basis, the cross-border transfer mechanism (Standard Contractual Clauses with the model provider), and the safeguards applied.
Regulatory framework.
The compliance position is published explicitly so it can be challenged. We name every framework that applies and where Fluxa sits within it.
EU AI Act (Regulation 2024/1689)
The Act’s high-risk categories (Annex III) include creditworthiness assessment and credit scoring of natural persons. Fluxa’s AI workforce does not perform these functions: KYB is for businesses, not natural persons, and decisions are human-made. The AI workforce sits in the Act’s limited-risk transparency tier (Article 50): users interacting with AI must be informed. This page is that disclosure. High-risk obligations under Articles 9 to 15 take effect on 2 August 2026.
GDPR Article 22
Article 22 prohibits decisions based solely on automated processing that produce legal or similarly significant effects. Fluxa does not make such decisions automatically. Every consequential decision is reviewed by a named human. The human review is substantive, with the source material visible to the reviewer. CJEU SCHUFA (C-634/21) is the controlling case law on what "substantive" means; the Fluxa approval flow is designed to that standard.
UK position
The UK’s pro-innovation approach (white paper, 2023, ongoing) is principles-based: safety, transparency, fairness, accountability, contestability. The FCA has set expectations for AI use in financial services around model risk management and consumer outcomes. Fluxa builds against both and against the EU AI Act, which is stricter, because we expect to serve UK and EU merchants.
ISO/IEC 42001:2023
The international AI management system standard. Fluxa’s internal governance (risk assessment, lifecycle controls, post-deployment monitoring, third-party provider oversight) is built against ISO/IEC 42001 clauses 4 to 10. Formal certification is a stretch target at this stage; the operational standard is held to today.
Sector frameworks
Where Fluxa interacts with PCI-DSS, MLR 2017, PSR 2017, and scheme rules, the AI workforce sits outside those scopes by design: it does not process card data, does not make AML decisions, does not move funds, does not change scheme-level behaviour. Sector compliance is documented separately on /security and /acceptable-use.
Audit trail and oversight.
The defining feature of a well-governed AI deployment is not the model but the audit trail. Every Fluxa AI action is logged as a byproduct of operation, not assembled after the fact.
What every log entry contains
Timestamp, agent name, agent version, prompt version, model and provider, input message or document (redacted where required), retrieved sources, draft output, escalation flags raised, reviewer identity, reviewer action (sent / edited / rejected), final sent output. Stored append-only, queryable, retained for seven years.
Right to challenge
Any merchant can ask for the log entries that relate to their account. They will receive a copy within ten working days, with personal data redacted where it relates to a third party. Where a draft was rejected or edited, the reviewer’s reason is included. Where a draft caused a problem, the same log lets us identify and fix the prompt or process that produced it.
Post-deployment monitoring
Each agent has a quality metric tracked weekly: how many drafts were sent without edit, how many were edited materially, how many were rejected outright. A rising rejection rate is a signal the prompt or the model needs work. Monitoring data is reviewed on the operating cadence and feeds into the prompt-versioning history.
Incident reporting
Where an AI-drafted output causes a material problem (a merchant complaint, a regulator query, a public-facing factual error), a written incident record is opened, the prompt or process is changed, and the incident is summarised at the next quarterly review. Material incidents are noted on the public changelog.
What AI never does.
The explicit boundary list. These actions are reserved to humans and the codebase enforces this with hard checks, not soft prompts. If an agent tries to take one of these actions, the call is blocked at the API layer.
Approve or reject a merchant
KYB and sanctions screening decisions are made by Fluxa against documented Money Laundering Regulations 2017 criteria. The AI workforce can pre-fill the review screen; it cannot click the approve button.
Move money or alter ledger state
Settlement holds, reserve releases, refund issuance, settlement schedule changes. None of these are agent-actionable. The agent cannot even call the ledger-write API; the credential it holds is read-only on those endpoints.
Resolve a complaint
Complaints are routed to a named human at Fluxa under the documented complaints procedure. The agent may help triage the inbound message into the right queue; it does not draft the substantive response and does not decide outcome.
Speak to a regulator or journalist
Any contact from a regulator (FCA, ICO, supervisory body) or a journalist goes to a senior team member directly. The agent flags the contact and pauses any drafting on that thread. Public statements are written by a human and reviewed before publication.
Make underwriting or pricing decisions
Pricing is the published flat rate. The founding-cohort rate (1.8% for twelve months) is published. Bespoke rates above £500k a month are agreed by founders, not by an agent. Risk underwriting decisions sit with the human reviewer against the documented eligibility criteria on /acceptable-use.
Authenticate, authorise or commit a card payment
The transaction path is entirely outside the AI workforce stack. Cards are handled by the PCI-DSS gateway and the payment partner; no AI agent has any read or write access to the card-data environment. This is enforced at the network layer, not just by convention.
How we built it.
Fluxa is a lean UK team. The AI workforce exists to let a lean team operate a payments business at a higher cadence without dropping the standard, not to replace the human work that has to be done well. The five agents handle the operational layer (drafting, parsing, watching, verifying, tracking); humans handle the decision layer (approving, rejecting, contesting, escalating).
Every agent is documented in code, prompt-versioned, logged on every action, and gated at the API layer for anything consequential. The compliance position (limited-risk transparency under the EU AI Act, no Article 22 automated decisions under GDPR, ISO/IEC 42001 governance as the operating standard) is held to today, regardless of which jurisdiction we are serving on a given week.
Material changes to scope, models, or boundaries are released-noted on the changelog before they go live, and this page is updated within five working days of any change that affects what is true here. Last reviewed May 2026. Next scheduled review August 2026.
If you have questions about how a specific message, decision, or outcome on your account was handled, write to support@fluxapay.co.uk and we will pull the log entry and explain what happened, who reviewed it and what the outcome was. The log exists precisely for this reason.