Answer the money question fast, and leave an audit trail.

Why fintech support carries more risk than volume

Most support teams are measured on throughput. In fintech, throughput is the easy part. A neobank with two hundred thousand accounts does not generate an unmanageable number of conversations; it generates a manageable number of conversations in which a wrong answer can cost the company a customer, a regulatory finding, or real money leaving the balance sheet. That asymmetry is the defining feature of the vertical and the reason most generic support playbooks import badly.

The failure modes below are the ones that show up in payments, lending and banking queues specifically. They are not the generic ones. Each has a mechanism, a cost that lands somewhere other than the support budget, and a set of standard responses that teams reach for and that reliably do not work. If you run support at a payment provider, a lending platform or a financial infrastructure company, you have probably tried at least three of the things in the "does not work" column, and you have probably been told by someone in compliance that the fourth is not allowed.

Every answer is a regulated communication

In ecommerce, a wrong answer costs you a refund. In fintech, a wrong answer is a statement your company made in writing about someone's money, and it is discoverable. That changes the physics of the queue completely.

The mechanism is that financial services communications sit inside a supervisory framework. Regulators and the firm's own compliance function care about whether statements to customers are fair, clear and not misleading; whether complaints were recognised as complaints and handled through the right process; whether promises about timing, eligibility or outcomes were accurate. None of that requires an agent to be malicious or even careless. It only requires them to be helpful in the way support agents are trained to be helpful. "Don't worry, that'll definitely be back in your account tomorrow" is exactly the kind of reassurance that makes a good agent feel good and creates an exposure the firm has to honour.

There is a second, subtler mechanism. In many jurisdictions and most internal policies, a customer expressing dissatisfaction triggers a formal process with its own clock, its own record-keeping and its own reporting. Whether a message counts as a complaint is frequently a judgement call made at speed by the most junior person in the organisation. Miscategorise it and the case never enters the process that was designed to protect both parties.

The cost is invisible until it is enormous. A support team that answers fast and loosely accumulates a liability that surfaces months later as a thematic review, a remediation exercise, or a pattern in complaints data that someone outside the company noticed before you did. Remediation is the expensive word here: once you have told two thousand customers something inaccurate, you do not fix it with a better macro, you fix it with a project, an outbound contact exercise and, often, redress.

What teams try that does not work: locking every reply behind a compliance-approved template library, which produces answers so hedged that customers write back three times and the real resolution happens in the fourth message anyway. Requiring second-line approval on anything sensitive, which sounds prudent and in practice means the sensitive tickets are the slowest ones, which is precisely backwards. Banning agents from giving timelines at all, which does not reduce the number of customers who need a timeline. Training on tone rather than on decision rules, so that agents learn which words to avoid without learning which answers are true.

What works is constraining the answer, not the phrasing. Define what the firm's actual position is on each recurring question, put it somewhere a system can read it, and make the default response come from that source rather than from an agent's recollection. That is a knowledge problem before it is a staffing problem, and it is the single highest-leverage unglamorous work in a fintech support function.

The customer is frightened, not annoyed

A late parcel produces irritation. A card declined at a supermarket checkout, a transfer that has not landed, an account frozen with a mortgage payment due — these produce fear, and fear is a different operating condition for both the customer and the agent.

The mechanism is that money is not a product category, it is an infrastructure that the customer's whole week depends on. When it stops working they do not experience a service failure, they experience loss of control. That has predictable behavioural consequences: they contact you repeatedly across every channel within minutes, they escalate to social media fast because visibility feels like leverage, they interpret neutral language as evasion, and they remember process explanations as excuses. A customer who sends five messages in ten minutes is not being unreasonable. They are doing the only thing available to them.

It also changes what "a good answer" means. In a retail queue, the accurate answer is usually the good answer. In a fintech queue, an accurate answer delivered without acknowledgement reads as contempt. "Your account is under review and we cannot share details" may be both true and required, and it will still produce an escalation unless it is paired with what the customer can know: that a human is on it, what happens next, when they will hear again, and what they should do about the payment due on Friday.

The cost lands in three places. Contact rate per case, because a frightened customer re-contacts, so one underlying problem becomes five conversations and your volume metrics stop meaning anything. Complaint volume, because fear converts to formal complaint faster than irritation does, and formal complaints are expensive to handle regardless of outcome. And agent attrition: taking calls from people who are scared about money, all day, is genuinely hard work, and teams that do not acknowledge that lose their best people to less demanding queues.

What teams try that does not work: empathy macros, which frightened customers detect immediately because the phrasing does not match the specifics of their situation. Auto-acknowledgements promising a response time the team cannot meet, which converts one anxious customer into one anxious and now betrayed customer. Routing "angry" tickets to a senior queue based on sentiment scoring, which mostly routes on punctuation. Hold music and callback promises on the phone line while the chat queue is empty.

What works is speed on the acknowledgement, honesty on the constraint, and specificity on the next step. Even when the substantive answer has to wait for a review team, the customer can be told within a minute that the case is open, what the process is, and when they will next hear from you — and that message can be accurate and automated. Separating "responding" from "resolving" is not a trick. It is the correct design for a queue where a meaningful share of cases cannot be resolved immediately by anyone.

Deadline-driven cases create SLAs you do not control

Most support SLAs are promises the company makes to itself. Fintech is full of clocks set by somebody else: card scheme dispute windows, the cadence of a verification review, the rhythm of settlement and reconciliation cycles, the point at which a lending decision expires and has to be re-run. Miss those and no amount of goodwill recovers the case.

The mechanism is that the deadline belongs to an external party — a card network, a banking partner, a sponsor bank, a processor, a bureau — and your queue is only one segment of a chain. When a customer disputes a transaction, evidence has to reach the acquirer, which has to reach the scheme, within a window the scheme defines. Your internal target of a two-day first response is irrelevant if the customer takes four days to send the receipt you asked for and the case then sits in a queue for three more. The clock did not care about your first response time. It cared about the last possible moment the file could be submitted.

Verification loops have the same shape with a nastier property: they are iterative. You ask for a document. The customer sends a photo with the corners cropped. You ask again. Each round trip consumes days of a window, and every round trip is an opportunity for the customer to give up — which, for an onboarding funnel, is churn paid for with marketing budget and, for an existing account, is a customer whose money is sitting somewhere they cannot reach it.

The cost is unusual because it is bimodal. Most deadline cases cost nothing extra; you make the window comfortably. The ones you miss cost the full amount at stake plus the fee plus the complaint plus, over time, a pattern that partners notice. Sponsor banks and processors look at dispute win rates and response timeliness. A queue that misses windows does not just lose individual cases; it becomes a topic in a partner review.

What teams try that does not work: managing deadlines in a spreadsheet maintained by one person, which works until that person takes leave. Setting a single blanket SLA across all ticket types, so a dispute with a hard external window is treated the same as a fee query. Chasing customers for documents once and marking the case "awaiting customer" forever, which is how a case quietly expires. Measuring first response time on deadline cases at all — the meaningful metric is time-to-submission-ready, and almost nobody tracks it.

What works is modelling the external deadline as a property of the ticket, driving reminders and escalation from it, and making the remaining time visible in the queue rather than in someone's head. A queue where SLA targets and assignment rules are set per case type, and where the countdown is on the ticket, turns a memory problem into an operational one.

Identity must come before the answer

In almost every other vertical, an agent can start being useful immediately. In fintech, the first several exchanges of most conversations are spent establishing who is talking and whether they are allowed to know the thing they are asking. That is not overhead to be optimised away. It is the load-bearing part.

The mechanism is that the value of the information is exactly what makes it dangerous to release. Balance, transaction history, address, card status, whether an account exists at all — each is useful to the account holder and useful to someone attempting to take over the account. Social engineering against support teams is a standard attack path precisely because agents are selected and trained to be helpful under pressure, and an attacker's entire method is to manufacture pressure. "I'm about to miss a payment, I just need to know if the transfer landed" is a sentence spoken far more often by genuine customers than by fraudsters, which is what makes it effective.

Authorisation is the second half and is routinely conflated with identity. Knowing that the person is who they say they are does not establish that they are entitled to act. Joint accounts, business accounts with multiple signatories, powers of attorney, deceased estates, a parent asking about a teenager's card, a bookkeeper asking about a company's payouts: each involves a verified human who may or may not have the right to the information or the action. Getting this wrong in the permissive direction is a data breach. Getting it wrong in the restrictive direction is the bereaved-customer story that goes viral.

The cost shows up as handle time on every single conversation, including the trivial ones, and as a floor under your automation rate that no amount of clever answering will get below. It also shows up as friction in the exact moments when friction is least tolerable — the customer who is already frightened now has to answer three questions before anyone will engage.

What teams try that does not work: knowledge-based questions about recent transactions, which are weak against anyone with access to the customer's email or device and infuriating for the genuine customer who cannot remember. Long static security-question lists, which end up written down somewhere insecure. Verifying once per customer rather than per conversation, so a stale session becomes a standing authorisation. Letting agents "use judgement" on verification, which produces inconsistency that an attacker will find by trying repeatedly.

What works is pushing verification into the authenticated surface wherever possible — in-app conversations where the session already proves identity are dramatically cheaper and safer than email — and treating out-of-band channels as unverified by default with a defined, uniform step-up. Where verification cannot be skipped, it should at least be consistent, logged, and completed before the case is worked rather than in the middle of it.

The audit trail is a product requirement

In most companies the support record is an internal convenience. In fintech it is evidence: for dispute representment, for complaints handling, for internal audit, for the partner bank's periodic review, and occasionally for a regulator or an ombudsman deciding whether the firm treated someone fairly. Designing your tooling as though the transcript were disposable is the mistake that costs the most later.

The mechanism is that financial cases get re-examined long after they close, by people who were not there. A dispute you decided against a customer in March may be reopened in September by an ombudsman scheme asking what evidence you considered. A frozen account may be reviewed by a financial crime team reconstructing a timeline. An audit sample may pull thirty conversations and ask, for each, who made the decision, what they saw, what policy they applied and whether they had the authority. If the answer to any of those lives only in an agent's memory or in a Slack DM, the answer is functionally "we do not know", and "we do not know" is the finding.

This is why side conversations matter more here than anywhere else. The real decision on a hard fintech case is frequently made in a message to the risk team. If that exchange happens in a private channel, the ticket shows an outcome with no reasoning, and the reasoning is the part that gets scrutinised. Side conversations attached to the ticket — the internal consult recorded against the case rather than beside it — are not a nice-to-have feature; they are how the record stays complete.

The cost of a thin audit trail is paid in three currencies. Time: reconstructing a case from four systems takes hours per case and the requests never come one at a time. Outcomes: disputes and ombudsman cases are decided on evidence, and an incomplete file loses cases you would otherwise have won. Trust: partners and auditors who find gaps do not conclude that one record was poor, they conclude that the control is unreliable, and the remediation scope expands accordingly.

What teams try that does not work: requiring agents to write a summary note at case close, which is the first thing dropped when the queue is deep and is written from memory when it is not. Exporting transcripts monthly to a document store nobody indexes. Relying on the ticketing tool's default retention, which is often wrong in both directions — too short for the cases that get reopened, too long for the data you should not be keeping. Treating chat, email and phone as separate archives, so reconstructing one customer's history requires three exports and a spreadsheet.

What works is a single record per customer across channels, internal consults attached to the case, decisions captured as structured fields rather than prose, and the ability to retrieve everything for one person quickly. That last capability doubles as your answer to data subject access requests, which is not a coincidence — the same architecture serves the audit and the customer's right to see their own file.

The fintech ticket taxonomy

Before automating anything, get an honest inventory of the queue. Most fintech support teams inherited a tagging scheme from a generic helpdesk template, extended it during an incident, and now have sixty tags of which eight get used. That matters more here than elsewhere, because your categories are also your risk categories: the tags are what compliance reports on, what the partner bank asks about, and what you will eventually automate against.

Shares vary enormously by business model. A card issuer's mix is dominated by transaction-level questions. A lending platform's is dominated by application status and repayment. A B2B payments infrastructure company has fewer, longer, more technical cases from developers rather than consumers. The table below therefore uses qualitative bands rather than invented precision. Measure your own; the ordering and the automation logic are the transferable parts.

One structural note before the detail. Automation potential is not automation priority. A category can be highly automatable and still be the wrong place to start if the blast radius of a wrong answer is large. In fintech the sensible sequence is to start where high volume, deterministic answers and low harm overlap — decline explanations, payment status, fee explanations — and to leave dispute decisions, limit increases and verification outcomes to humans for as long as it takes to trust the surrounding data. If you need a framework for what "resolved" even means before measuring it, the resolution rate guide covers the definitional traps that make fintech numbers particularly easy to fake.

Declined payments and failed transactions

This is the highest-volume category in most consumer fintech queues and the one where the customer is most acutely uncomfortable, because the failure usually happened in public. Good resolution is not "the transaction was declined". The customer knows that; they were standing there. Good resolution is the specific reason, in plain language, plus the specific action that makes the next attempt succeed.

Decline reasons fall into a small number of buckets and they need different answers. Insufficient funds or an uncleared balance. A limit breached — daily spend, per-transaction, ATM, contactless before re-authentication. A risk rule triggered by geography, merchant category, velocity or a mismatch with normal behaviour. A card state issue: expired, frozen, not yet activated, reported lost. A technical failure at the merchant, the acquirer or the network, which is not your fault and is still your ticket. And authentication failures, where a step-up challenge was issued and not completed — very often because the customer's phone number or app notification setup is stale.

The data required: the authorisation record with the response code and any issuer-side reason, the merchant descriptor and category, the customer's current limits and how much of each is consumed, available versus ledger balance including holds, the card's state, and the risk decision if one was made. Holds matter more than teams expect. A pre-authorisation from a hotel or a fuel pump can make a balance look wrong for days, and explaining that mechanism resolves a conversation that would otherwise become a complaint.

Automation potential is high because the mapping from reason code to explanation to remedy is deterministic. An agent that can read the authorisation and the limit state can answer most of these end to end, including the useful next step — unfreeze the card, complete the pending challenge, retry after the hold releases, use a different rail for this amount.

Where a human must decide: when the decline was risk-driven and the customer wants the rule relaxed. Overriding a risk decision is a risk decision, and it belongs to someone with the authority and the context to make it, not to whoever picked up the chat. Also human: any case where the pattern suggests the customer's card is compromised, and any case where the customer reports a transaction they did not attempt, which is a fraud report wearing a decline ticket's clothing.

Payment status and settlement timing

"Where is my money" is fintech's version of WISMO, and it has the same properties: high volume, highly predictable, and almost entirely caused by a gap between what the customer can see and what the business knows. The customer sees a transfer marked "sent" and a recipient saying nothing arrived. You can see which rail it went on, whether it cleared your cut-off, whether it is sitting in a batch, whether it was held for screening, and what the receiving institution typically does with it.

Good resolution is a state and a date. Not "it's processing" — the customer read that. Where the payment actually is in the chain, why it looks stalled if it does, when it will realistically land, and what happens if it does not. For payouts to merchants or sellers, the same applies at batch level: which payouts are in which batch, when that batch settles, and whether a reserve or rolling hold is affecting the amount.

The data required: the transaction record with its full state history rather than the current status string, the rail and its operating hours and cut-offs, the settlement or payout batch it belongs to, any screening or compliance hold, beneficiary details as submitted, and for cross-border, the correspondent chain and the fee and rate applied. Weekend and holiday calendars matter, and they differ by rail and by country. A payment sent on a Friday evening onto a rail that settles on business days is not stuck; it is early in a queue, and saying so precisely is the whole resolution.

Automation potential is high. This is a lookup, a translation and a calculation against a schedule, and it is exactly the work that should never occupy a trained agent. It is also the category that most benefits from getting ahead of the ticket: if a batch is delayed or a rail is degraded, a proactive message to affected customers removes more volume than any amount of faster answering.

Where a human must decide: suspected misdirected payments, where the money reached a real account belonging to the wrong person and recovery depends on another institution's cooperation. Payments held for screening, where what you may tell the customer is constrained and the framing has to be right. And any case where the customer's account of events and the system's record disagree materially, because that is either a defect or a fraud, and both need a person.

Disputes and chargebacks

Disputes are low volume relative to the queue and high enough in cost that they deserve a dedicated operating model. The mechanics matter, so be precise about them internally: when a cardholder disputes a transaction, the case moves through a defined process between issuer, network and acquirer, evidence is exchanged within windows the scheme sets, and the outcome depends on which party's evidence better matches the reason code claimed. Different reason codes require genuinely different evidence. Treating them as one workflow is the most common structural error.

Good resolution has two halves that are easy to confuse. For the customer, it is clarity: what the process is, what a provisional credit does and does not mean, what you need from them, and when they will know. For the business, it is a well-built evidence file submitted comfortably inside the window. A case can be handled beautifully for the customer and lost operationally because a receipt arrived two days after submission.

The data required: the full transaction detail including merchant descriptor, terminal and authentication data; the customer's statement of what happened, captured in a structured way rather than as free text; prior disputes by this customer; whether the customer contacted the merchant first, which several reason codes effectively require; the merchant's response if any; and the scheme's evidence requirements for that specific code. Your own support transcript is part of the file — a conversation where you offered a remedy the customer declined is material evidence, which is one more reason the record has to be retrievable in seconds.

Automation potential is medium, and it sits entirely on the intake and status sides. Gathering the customer's account, prompting for the exact documents the reason code needs, validating that what they uploaded is legible, keeping them informed at each stage, and chasing missing items before the window closes — all of that is mechanical and all of it currently eats analyst time. An AI agent that resolves rather than deflects is well suited to the intake conversation precisely because it is patient about asking for the fourth document.

Where a human must decide: the substantive call and the evidence framing, always. Also the pattern cases — the customer whose dispute history suggests first-party misuse — which need a person, a conversation and a documented decision, not an automatic outcome in either direction.

Identity verification and KYC loops

Verification tickets cluster at onboarding and at trigger events: a large first deposit, a change of address, a periodic refresh, a product upgrade. They share one damaging property — the customer is blocked, and every extra round trip raises the chance they abandon. For an onboarding funnel that abandonment is acquisition spend set on fire. For an existing customer with a balance, it is a complaint waiting to happen.

Good resolution is a single, specific, first-time-right request. Not "please upload proof of address" but "we need a document dated within the last few months showing your name and the address on your account; a bank statement or a utility bill works, a screenshot of an app does not, and all four corners must be visible". Most verification loops are long because the first request was vague. The second most common cause is that the system rejected an upload without telling the customer which part failed.

The data required: the verification case and its current state, exactly which checks passed and failed, what has already been submitted so you never ask twice, the document standards for the customer's country and product, and the reason for the request in language you are permitted to use. That last point is a real constraint — some review reasons cannot be shared — and the correct response is to be clear about what you can say rather than to be vague about everything.

Automation potential is medium to high on the loop and zero on the outcome. Explaining requirements, checking a submission against basic quality criteria before it reaches a reviewer, telling the customer exactly why the last attempt failed, and updating them on state changes are all automatable and all currently consume trained reviewers' time. Multilingual handling matters disproportionately here, because document requirements are hard to express clearly even in a customer's first language; drafting and two-way translation for agents removes a category of loop that exists purely because the instruction was misunderstood.

Where a human must decide: every approve or decline, every enhanced due diligence case, and every situation where a customer's circumstances do not fit the standard document set — recent movers, people without conventional address documentation, customers whose legal name differs from their document name. Those are exactly the cases where an automated rejection produces both an unfair outcome and a story.

Account access and lockouts

Access tickets are urgent by definition and dangerous by definition, and those two facts pull in opposite directions. The customer is locked out and needs back in now. The person claiming to be locked out is also the exact profile of an account takeover attempt. Every access process is a negotiation between those two truths, and the queue is where the negotiation happens.

Good resolution restores access through a path that proves control of something the attacker does not have, and does it without a human relaxing a control because the customer was upset. The best outcomes come from self-service recovery paths that are strong enough to be trusted and clear enough to be completed — which means the support conversation's job is often to guide someone through a recovery flow rather than to perform the recovery.

Common causes, and they need different handling: forgotten credentials, a lost or changed phone that took the authenticator with it, a new device triggering a step-up the customer cannot complete, a lockout after repeated failed attempts, a deliberate freeze following a risk signal, and a genuine takeover where the attacker has already changed the recovery details. The last of these is the one your process must be designed around, because it is the one where every helpful instinct is wrong.

The data required: authentication logs including device, location and recent failures; which recovery factors are registered and when they were last changed; the reason for any deliberate lock; open sessions; and recent account activity that would indicate compromise. A recovery detail changed shortly before a support contact is the single most important signal in this category and should be surfaced automatically rather than discovered by an alert agent.

Automation potential is medium. Explaining the recovery path, walking a customer through it, confirming state changes, and handling the large share of cases that are simply a forgotten credential all automate cleanly within an authenticated session. Anything that involves changing a security factor from an unauthenticated channel should not.

Where a human must decide: any case with a takeover signal, any request to change a recovery factor where the existing factor cannot be used, and any case where the customer cannot complete the standard path. Those need a person with a defined step-up procedure, a decision they are authorised to make, and a record of what evidence they accepted.

Limits and authorisation requests

Limit tickets look administrative and are actually risk conversations. A customer wants to send more than their transfer limit, spend more on their card, withdraw more cash, or take a larger credit line. Some limits are regulatory or partner-imposed, some are risk-based, some are product tiers, and some are affordability-driven on credit products. The customer experiences all of them as one arbitrary obstacle, so the first job is explaining which kind they have hit.

Good resolution is a clear statement of the applicable limit, what governs it, the concrete route to a higher one if a route exists, and an honest "no, and here is why" if it does not. Ambiguity here is costly: a customer who believes a limit is negotiable will keep contacting you until someone says no clearly, and each of those contacts is a chance for an inconsistent answer to appear in writing.

The data required: the current limit set and consumption against each, the policy that sets each limit and whether it is fixed or reviewable, the account's tenure and history, verification tier, and for credit products the affordability and risk inputs behind the decision. You also need the pathway data: what a customer must do to qualify for the next tier, and how long the review takes.

Automation potential is low to medium, and this is one of the places to be deliberately conservative. Explaining limits, showing consumption, describing the upgrade path and collecting the information an increase request needs are all automatable. Granting an increase is not, wherever the limit is risk- or affordability-based, because that is a credit or risk decision with regulatory weight and it belongs inside the decisioning system with a recorded rationale. Where limits are purely tier-based and the tier is mechanically earned, automation is appropriate and should be explicit about the rule it applied.

Where a human must decide: every discretionary increase, every temporary exception — the customer buying a car today — and every case where a customer pushes back on a declined increase. That last one frequently contains a complaint and should be recognised as such rather than answered as a repeat request. Consistency matters more than generosity here; two customers with similar profiles receiving different answers is the pattern that turns into a fairness finding.

Fees and statement questions

Fee tickets are steady-state volume that spikes hard after any pricing change, and they are almost entirely self-inflicted. The customer sees a charge they did not expect, or a total that does not match what they calculated, or a foreign transaction that converted at a rate they cannot reproduce. Each of these is a communication defect that arrived in the queue.

Good resolution is an itemised explanation in plain language, tied to the specific transaction, referencing the actual fee schedule that applied at the time. "That £2.50 is the out-of-network ATM fee; here is the line in your plan, and here is how to avoid it next time" resolves. "Please refer to our fees page" does not, and generates a second ticket with a worse tone. For currency conversion, the explanation needs to separate the exchange rate applied, the timestamp it was applied at, and any separate fee — customers who compare your rate to a mid-market rate they saw online are not being difficult, they are comparing two different numbers and nobody told them.

The data required: the charged item with its type and timestamp, the fee schedule version in force for that customer at that moment, the plan or tier they are on, the rate applied and its source, and the full statement line context including any related holds or adjustments. Fee schedule versioning is the piece most teams lack, and it is what makes answering a question about a charge from two months ago either trivial or impossible.

Automation potential is high. These are deterministic lookups with deterministic explanations, and a system with the fee schedule in a knowledge base the agent answers from plus transaction access resolves the large majority end to end, in any language, at any hour.

Where a human must decide: goodwill reversals above whatever ceiling policy sets, and any case that suggests the charge itself was wrong. That second one matters more than the individual ticket, because a genuine fee error is rarely isolated. If one customer was charged incorrectly, a cohort was, and the support queue is where that gets detected first. Escalating the pattern with volume attached is worth more than resolving the tickets faster.

Refunds and reversals

Refunds in fintech carry the retail problem — the gap between when you send money and when the customer sees it — plus a set of complications that retail does not have. The customer may be asking about a merchant refund you do not control, a reversal of a failed transfer, the return of a duplicate charge, or remediation for an error your system made. Those are four different processes and the customer describes all of them as "I want my money back".

Good resolution starts by correctly classifying which of those it is, because the honest answer differs. For a merchant refund, your role is visibility and timing, not control, and pretending otherwise creates a promise you cannot keep. For a reversal on a failed payment, the money is typically returning through the rail and the answer is state and timing. For a duplicate charge, the answer is a correction and a date. For remediation of your own error, the answer is the money plus an acknowledgement that does not read like a template.

The data required: the original transaction and its authorisation, any pending or settled refund against it, the counterparty's status where visible, the rail and its return timing, prior partial refunds, and whether a hold is still in place — a released pre-authorisation and an issued refund look identical to a customer and behave differently.

Automation potential is medium to high on status, timing and duplicate detection. Proactive messages when a refund posts remove a meaningful share of follow-up contacts, and explaining the difference between "we have sent it" and "your bank has posted it" in one accurate message is the highest-yield sentence in the category.

Where a human must decide: remediation for firm error, especially where a customer suffered a consequential loss such as a missed payment or a returned direct debit, because the right outcome may exceed the transaction value and that is a judgement. Also anything above a defined value, and any refund request that is really a dispute — a customer who says the merchant took money they did not authorise has raised a fraud claim, and routing it as a refund loses both the evidence and the clock.

Account closure and data requests

Low volume, disproportionate compliance weight, and usually handled worst because nobody owns it. A customer wants to close their account, or wants a copy of their data, or wants information deleted. These arrive in the same queue as a fee question and carry entirely different obligations.

Good resolution for closure is a clean, dignified exit: confirm the closing balance and where it is going, identify pending transactions and standing instructions that will fail after closure, explain what happens to any linked products, state what records the firm must retain and why, and confirm when it is done. Adding retention friction here is counterproductive in a way that is easy to measure — a customer prevented from closing an account escalates, complains publicly, and sometimes disputes charges, all of which cost more than the account was worth. Make the save offer good rather than the exit hard.

Good resolution for a data request is a complete, timely response through a defined process. The operational difficulty is that "everything you hold about me" spans the core platform, the support record, marketing systems and logs. If your support transcripts live in three places, the request becomes a project every single time.

The data required: balance and pending items, scheduled payments and incoming instructions, any outstanding obligation such as a loan balance or a negative balance, the retention rules that apply, and a map of where customer data lives. For closures driven by the firm rather than the customer — a risk-based exit — what you may say is constrained, and the constraint should be defined in advance rather than improvised.

Automation potential is medium. Explaining the process, surfacing what will break on closure, confirming balances and destinations, acknowledging a data request and confirming its scope are all mechanical. The execution and any disclosure decision are not.

Where a human must decide: closures with outstanding obligations, closures where a dispute or investigation is open, every firm-initiated exit, and the scope decision on any data request where some information is properly withheld. Route these to a named owner with the authority to decide, and record the reasoning on the case — because this is the category most likely to be read back to you by someone external months later.

How Aftersales resolves fintech conversations

Support in a financial product splits cleanly into two halves, and most teams never draw the line explicitly. One half is explanation: the customer does not understand what happened to their money, their account or their application, and the answer already exists somewhere in a system of record. The other half is decision: someone has to approve, release, reverse, unlock or refuse, and that act has consequences a company can be held to.

An AI agent belongs entirely in the first half. It can be extremely good there — better than a rota, because it reads every relevant object before it types and it never gets tired at the end of a shift. It has no business in the second half at all.

What follows is five walkthroughs. Each traces a message from arrival to logged outcome: what Agent retrieves, the branch points, the reply it writes, and the record it leaves behind. One constraint runs through all of them. Aftersales ships integrations with Shopify, Stripe, Salesforce, Zendesk, Freshdesk, WhatsApp, email, SMS and Slack. A core banking platform, a card processor's own ledger, a KYC vendor or an internal risk engine reaches Aftersales through the API, which means the fields Agent can read are the fields you choose to expose and the actions it can take are the actions you choose to define. That is not a limitation to work around. It is the control surface.

1. Explaining a declined payment without exposing card data

The message. 7:12pm, in-app chat, escalated to email: "My card just got declined twice at the supermarket and I know there's money in the account. Extremely embarrassing. What is going on?" The customer is verified in-session. The tone is not a billing query; it is a dignity query, and the first sentence of the reply has to acknowledge that before it explains anything.

What Agent retrieves. Three layers, in order. First, the authorisation attempts themselves. Where the payment ran through Stripe, Agent reads the payment intent objects for the last hour: two attempts, both declined, each with an outcome reason and a network decline code. Second, the account-side context, exposed through the API: available balance versus ledger balance, pending holds, any card-level state such as frozen, expired or newly reissued, and whether a spending control or category block is active. Third, the pattern. Has this card been declined before this week? Is there an open fraud review on the account? Did the customer travel, and is there a geography rule in play?

Agent does not retrieve, and cannot retrieve, the full PAN. It works with the last four digits, the card brand, the expiry state and the token reference. That is not a workaround for a missing feature; it is how the field mapping is configured when you connect the account system through the API. Sensitive fields are simply not in the payload, so there is no path by which a clever prompt produces them.

The decision logic. Decline reasons fall into families, and the family determines who answers. Issuer-side declines with a mechanical cause — expired card, incorrect CVC, a card that was reissued and not activated — are fully explainable and fully fixable by the customer. Balance-related declines are explainable too, but require care: the difference between available and ledger balance, caused by a pending hold from a fuel station or hotel, is the single most common "I know I had money" case and it resolves the moment someone explains holds properly. Merchant-category or spending-control declines are explainable if the control is one the customer set themselves. Risk-engine declines are the hard branch. If the decline came from a fraud model, Agent explains that the transaction was stopped by a security check, does not describe the rule that fired, and hands to the risk queue.

This case lands in the hold branch. Ledger balance shows funds. Available balance is lower by the amount of a pending pre-authorisation from a fuel purchase two days earlier. The second decline is a retry of the first, not a separate event.

The reply. It opens by acknowledging that being declined in a queue is horrible and that the account is fine. Then the mechanism, in short sentences: a pre-authorisation from Tuesday is still holding funds, that hold releases when the merchant finalises the amount, and the figure the app shows as available is the figure the card can spend against. It names the amount held and the date it will drop off if the merchant does not settle sooner. It names the card by last four digits so the customer knows which one is being discussed. It does not say "please try again later" without saying what will be different later.

Where it stops. If the decline came from the fraud model, Agent explains the category, states that a specialist will review it, and says when. It does not release the block, does not whitelist the merchant, and does not tell the customer the transaction will go through next time — because it might not, and a promise Agent cannot keep is worse than a transfer. If the customer says the transaction was not theirs, the conversation stops being a decline explanation and becomes a potential fraud report, which routes immediately regardless of what else is in the thread.

The logged outcome. Resolved by Agent, tagged payments/decline-pending-hold, with the decline codes and the payment intent references written into the conversation record and no account state changed. Nothing about the card beyond its last four digits and brand appears anywhere in the transcript, which matters when that transcript is retained for years and read by people who were not in the conversation.

2. Payment and settlement status questions

The message. WhatsApp, Thursday morning, from a business customer: "Sent a payment Tuesday afternoon to our supplier, they say nothing has landed, they're threatening to hold our order. Can you check." Two facts, one deadline, and a supplier relationship on the line.

What Agent retrieves. The payment record first: initiated timestamp, amount, currency, rail used, current status, and — the field that resolves most of these — the scheme or reference identifier that proves the payment left. Then the timing model for that rail. Instant domestic rails and batch rails behave completely differently, and cross-border payments behave differently again depending on cut-off times, intermediary banks, correspondent routing and whether the destination market was closed for a public holiday. Agent reads the cut-off configuration and the calendar from Knowledge rather than guessing from the clock.

It also checks the three states that look like a delay and are not: a payment returned by the beneficiary bank for a name or account mismatch, a payment held pending a compliance screen, and a payment that succeeded but to a different beneficiary than the customer believes because they selected a saved payee.

Where the money movement originated as a card payment rather than a bank transfer — common for platform and marketplace customers — Stripe gives Agent the payout and balance-transaction objects: when the payout was created, its arrival estimate, whether it is in transit or paid, and whether a payout was blocked by a negative balance.

The decision logic. If the payment shows as sent and the elapsed time sits inside the normal window for that rail and corridor, Agent explains where it is and when it lands. That is a lookup, not a decision, and it should be answered in full. If the elapsed time is outside the window, Agent does not speculate about the beneficiary bank. It gathers what a trace requires — reference, date, amount, beneficiary details as held on file — and routes to the payments operations queue with all of it attached. If the payment is held on a compliance screen, Agent says the payment is under review, does not describe the screening criteria, and routes. If the payment was returned, Agent states the return and the reason category, and hands the correction to a human because re-sending a payment is money movement.

The reply. For this customer, the payment left Tuesday at 16:40, after the same-day cut-off for the corridor, and the destination market was closed Wednesday. Agent says exactly that, gives the reference the supplier's bank can quote, states the expected arrival, and offers to send a written confirmation of despatch the customer can forward. That last offer is the one that saves the relationship, because the customer's real problem is not knowing where the money is — it is having nothing to show the supplier.

Why the reference matters more than the reassurance. Business payment queries are proxies for a conversation happening somewhere else. The customer is not going to relay your reassurance; they are going to forward a document. An agent that ends the conversation with a quotable reference and a timestamp resolves two conversations. An agent that ends with "it should arrive soon" resolves none and will hear from the customer again within four hours.

The logged outcome. Resolved by Agent, tagged payments/settlement-timing and segment/business, payment reference attached, confirmation document sent and logged as an outbound artefact. No funds moved, no beneficiary details changed, no payment re-initiated. Repeated volume on this tag against one corridor is a product signal, not a support signal — it usually means the cut-off time is displayed somewhere the customer does not look, and Insights is where that becomes visible.

3. Guiding a verification upload, handing the decision to a human

The message. Email, Sunday night: "You've asked me for proof of address for the third time. I've sent my bank statement twice. What exactly do you want?" This customer is not confused. They are angry at a process that has failed to explain itself, which is the most common failure mode in onboarding and remediation queues.

What Agent retrieves. The verification case record, exposed through the API from whichever KYC or case-management system holds it: which checks are outstanding, which documents have been submitted, the rejection reason on each prior submission, and the deadline if one applies. Then the document requirements from Knowledge: accepted document types, acceptable age of a document, whether a scan is acceptable or a full-page photo is required, whether the name must match the account exactly, and which file formats and size limits the upload path accepts.

Reading the rejection reasons is the whole job here. In this case the two bank statements were rejected because both were cropped screenshots showing the address but not the issuing bank's header or the statement date. Nobody had told the customer that. The rejection notice said "document did not meet requirements", which is the sort of message that generates the third contact.

The decision logic. Agent may explain requirements, diagnose why a specific submission failed if the reason is recorded, guide the customer through producing a compliant document, and receive the upload. It may confirm that the file arrived, is readable, and is of an accepted type. It may tell the customer what happens next and when.

Agent may not decide whether the document satisfies the check. That is an identity decision. It does not matter how confident the model is that the address matches; a verification outcome carries regulatory weight, has to be attributable to a reviewer, and in many regimes has to be capable of being explained and defended later. So Agent's last act in this conversation is to place a complete case in front of a named human, not to approve anything.

It also may not tell the customer their account will be unblocked, may not extend a deadline, and may not state that the document "looks fine" — a phrase customers reasonably hear as approval.

The reply. Three short messages on the channel the customer used. The first says plainly what went wrong: both statements were cropped, and the reviewer needs to see the bank's name, the customer's name, the address and the statement date in one uncut image. The second lists what will be accepted, concretely — a full-page PDF downloaded from the banking app is the easiest route, dated within the accepted window — and gives the upload link. The third sets the expectation: once uploaded, a reviewer checks it, typically within a stated turnaround, and the customer will hear either way.

The customer uploads a full PDF eleven minutes later. Agent confirms receipt, confirms the file is legible and of an accepted type, and says a reviewer now has it. It does not say "that's perfect".

The handoff. The case reaches the verification queue in Inbox as one thread with the document attached, the two prior rejection reasons visible, the outstanding checks listed, and the deadline showing as a countdown rather than a date buried in a field. The reviewer's job is a judgement, and everything mechanical has already been done.

Why guiding is worth so much here. Verification abandonment is expensive in a way that support metrics rarely capture. A customer who gives up halfway through remediation is either a lost account or, worse, a dormant account you still have obligations toward. Most abandonment is not reluctance; it is friction — an unclear requirement, a failed upload on mobile, a rejection notice with no reason. An agent available at 10pm on a Sunday that explains the exact defect in the exact document removes the friction at the moment the customer is actually holding their phone.

The logged outcome. Escalated to a human reviewer, tagged verification/proof-of-address and verification/repeat-rejection, with Agent's guidance recorded, the upload timestamped, and the decision left blank until a reviewer makes it. The repeat-rejection tag is the useful one. A cluster of it against one document type means the rejection notices are not explaining themselves, and fixing the notice removes hundreds of conversations that currently exist only because a form was vague.

4. Opening a dispute correctly

The message. SMS, 08:05: "There's a £240 charge on my card from a company I've never heard of. I want my money back today." Verified customer, high emotion, and a clock that started before the message arrived.

What Agent retrieves. The transaction itself: merchant descriptor, amount, date, card used, whether it was card-present or online, whether it was 3-D Secure authenticated, and whether it is still pending or has settled. Then the customer's own history against that merchant — descriptors are frequently a parent company name the customer does not recognise, and a meaningful share of these resolve in one message when Agent can say "this descriptor belongs to the subscription you set up in March". Then any recurring pattern: is this the fourth instalment of something? Is there a matching authorisation and capture that the customer has read as two charges?

Then the process facts from Knowledge: what the dispute categories are, what evidence each requires, what the scheme timelines are in broad terms, and what the customer must do versus what the company does.

The decision logic. Agent's first duty is to rule out the non-disputes, because opening a chargeback that should never have existed costs the customer time and the company a case. Descriptor confusion, forgotten subscriptions, family members on a supplementary card, pending authorisations mistaken for duplicate charges — all of these are resolvable in the conversation. Agent checks them in order and only proceeds once none apply.

If it is a genuine dispute, Agent moves into evidence gathering. What the customer needs to state, it asks for in a structured sequence, one question per message: did they authorise the transaction in any form, have they contacted the merchant, do they still have the goods or service, when did they first notice, and is the card still in their possession. That last one branches hard. A card the customer no longer holds is a fraud case, not a dispute, and it goes to the fraud queue immediately with the card-block request flagged for a human to action.

Agent does not decide the dispute category. It gathers the facts that let a specialist categorise correctly, because category determines the evidence rules and a miscategorised case tends to lose.

The reply and the expectation-setting. This is the part most teams do worst. The customer asked for their money back today. Agent must not promise that, must not imply it, and must not hide behind vagueness either. The honest version is specific: the transaction is being disputed, a specialist will confirm the category and submit it, the scheme process takes time and the outcome is decided by the card networks rather than by the company, provisional credit — if your product offers it — is a decision a specialist makes and not something Agent can grant. Then the one thing that genuinely calms people: what happens next, who does it, and when they will hear.

Agent also tells the customer what would harm the case, which nobody thinks to do. Continuing to use a disputed subscription, or accepting a partial refund directly from the merchant mid-case, complicates things. Thirty seconds of explanation prevents a lost case three weeks later.

The routing. Straight to the disputes specialist queue, with the evidence pack assembled: transaction object, authentication status, the customer's answers in their own words, prior merchant history, and the clock. Never to a general queue. Dispute work is deadline-bound and specialist, and Workflows should route it on the tag, not on availability.

The logged outcome. Escalated, tagged disputes/unrecognised-transaction, evidence captured, deadline attached, no funds moved and no provisional credit issued. If the descriptor check had resolved it, the outcome would have been the opposite and just as valuable: resolved by Agent, tagged disputes/descriptor-confusion, with no chargeback raised — a case avoided is a better result than a case won.

5. Account access and lockout recovery

The message. 23:40, email from the address on file: "I'm locked out. It says too many attempts and the code isn't arriving. I need to pay my rent tomorrow morning." Genuine urgency, and the exact shape of message a social engineer also sends.

What Agent retrieves. The account's authentication state: is it locked, for how long, on what trigger, how many failed attempts, and from what device and general location. Whether the registered phone number changed recently. Whether one-time codes were despatched and what the delivery status was. Whether there is an active fraud flag or a recent device registration. Whether the customer has contacted before this week about the same thing.

The decision logic, and the line Agent does not cross. Agent may verify context. It may confirm that the email matches the account of record, that a lockout exists and when it expires, that codes were sent and to which masked number, and that no other action is required. It may explain the mechanism — why a temporary lock exists, what resets it, why codes sometimes fail to arrive on certain networks or when a phone has a carrier block on short codes.

Agent may not authenticate anyone. It may not clear the lock, reset a password, disable multi-factor authentication, register a new device, change a phone number or email, or approve any recovery path. Every one of those is the authentication decision itself, and an agent that can be talked into any of them is the vulnerability, not the feature. This matters most exactly when the message is urgent and sympathetic, because that is the pretext an attacker chooses. The correct behaviour is that urgency changes the speed of the handoff and nothing else about the authority.

There is one more subtlety. Agent must not leak account existence or state to an unverified sender. If the message arrives from an address that is not on file, the response is deliberately uninformative: it does not confirm an account exists, does not confirm a lockout, and directs the sender through the standard recovery path. Being unhelpful to a stranger is correct behaviour.

The reply. For this verified case, Agent explains that the account is under a temporary lock triggered by repeated failed attempts, states when the lock lifts automatically, and confirms that codes were sent to a number ending in the digits the customer can check. It explains the two common reasons codes fail to arrive and the one thing worth trying. Then, because the customer has a rent payment tomorrow, it does the useful thing: it flags the conversation for the account-security queue with the deadline attached so a reviewer can run proper identity verification first thing, and it tells the customer that is happening and when. It does not tell them the lock will be lifted, because that is the reviewer's call.

Why "a specialist will confirm this" is the right answer at midnight. A customer locked out at 23:40 wants to be back in at 23:41. They cannot be, and no honest system will let them be, because the fastest possible path to their account is also the fastest possible path for someone impersonating them. What Agent can do is remove every avoidable minute from the rest of it: verify the context, explain the mechanism, assemble the case, put it in a queue with a clock on it, and tell the customer precisely what happens next. That is a good experience delivered inside a hard constraint, which is the only kind of good experience available here.

The logged outcome. Escalated, tagged access/lockout with a deadline/customer-stated marker, no credential changed, no MFA state touched, every retrieval Agent performed recorded. The last point matters. In an account-takeover investigation, the question "what did the support system tell whoever was in that conversation" gets asked, and the answer needs to be a log rather than a recollection.

The authority boundary: what Agent must never do alone

Every other design question in fintech support is downstream of this one. Get the boundary right and an agent that occasionally writes an awkward sentence is a manageable problem. Get it wrong and a fluent, confident system is authorised to do things nobody intended, at three in the morning, to a customer who may not be who they say they are.

The boundary is not a tone setting or a system prompt instruction. It is a set of hard constraints on which actions exist in Agent's action space at all. If refunding is not a defined action, no phrasing produces a refund. That is the distinction between a policy and a control, and only one of them survives contact with a determined adversary.

Read the right-hand column as the actual rule. The pattern is consistent: Agent operates freely on anything that describes state, and not at all on anything that changes state in a way involving money, identity, credit, access or commitment.

Configuring the limits so they hold

Three implementation details separate a boundary that works from one that reads well in a slide.

Define the action space, then the guardrail — in that order. The tempting approach is to give Agent broad capability and constrain it with instructions. It is the wrong order. Start from zero actions and add each one deliberately, with its own conditions, its own value ceilings where relevant, and its own logging. An action Agent cannot invoke needs no guardrail.

Put ceilings in two dimensions. Where you do permit a bounded financial action — a small fee waiver, say — set both a per-conversation limit and an aggregate limit over a rolling window. The aggregate is the one people skip and the one that saves you. A per-case waiver limit looks safe right up until a pricing bug produces four hundred identical complaints in an afternoon. The aggregate ceiling trips, automation stops, the queue routes to humans, and somebody investigates. That is a circuit breaker doing its job.

Fail closed, not open. When Agent is uncertain — the retrieval came back thin, the account state is ambiguous, the customer's request does not map cleanly to a known category, an upstream system times out — the default must be to stop and route, never to proceed on a best guess. Failing open in a retail context produces a slightly wrong answer about a jacket. Failing open in a financial context produces a wrong statement about someone's money, made in writing, by a system the customer reasonably believes speaks for the company.

Specify what "uncertain" means, too, because it is not one thing. Retrieval confidence asks whether a source that actually answers this was found. Interpretation confidence asks whether Agent understands what is being requested. Action confidence — which barely applies here, since the permitted actions are so narrow — asks whether the conditions for a bounded action are genuinely met. The first two should be tuned conservatively. The third should be set so tightly that it almost never fires.

Why "a specialist will confirm this" is the correct behaviour

There is a widespread and damaging assumption that every handoff is an automation failure. Measured on deflection rate, it is. Measured on whether the customer got a correct outcome, it is frequently the only acceptable move.

Think about the asymmetry. A customer told "I can see the charge, I've passed this to the disputes team with everything they need, and you'll hear from them within four working hours" has had a competent experience. Slower than they wanted, but they were taken seriously and something is happening. A customer told, confidently and wrongly, that their money will be back today has had a good experience for about eighteen hours and a much worse one afterwards — plus a second contact, a complaint, and a permanent belief that nothing the company says can be trusted.

The internal cost runs the same direction. A wrong refund is a reconciliation entry someone unwinds by hand. A wrong eligibility statement is a complaint that may be reportable. A wrong unlock is an incident. None of these appear in a deflection metric, which is precisely why per-resolution pricing models deserve scrutiny before adoption — Intercom's Fin charges $0.99 per resolution, which quietly rewards calling things resolved. Aftersales prices per seat from $24 a month, so a correct escalation costs exactly what a correct resolution costs and nobody in the building is nudged toward the wrong one. The comparison with Intercom alternatives goes into the mechanics.

The customer-facing version of this needs writing properly, and most teams leave it to chance. "A specialist will confirm this" is only reassuring when it comes with three things: what the specialist will actually do, when, and what the customer should do in the meantime, including nothing if that is the honest answer. Without those, it is a brush-off with extra words.

One final point on configuration. Review the boundary on a schedule, not on incident. The pressure over time is always toward loosening it, because every individual request to let Agent do one more small thing sounds reasonable on its own. Keep a written record of what Agent is permitted to do and why, treat changes to it as changes to a control, and make sure the person who approves those changes is not the person whose queue volume they reduce.

Handoff under a deadline

Retail support handoffs are graded on minutes. Fintech handoffs are graded on whether they beat a clock that is usually external, usually unforgiving, and usually invisible in a standard helpdesk view. Scheme dispute windows, verification deadlines attached to a case, regulatory complaint timelines, payment trace windows — none of these care how busy your queue was.

This changes what a handoff has to carry.

What must travel

The deadline itself, as a live countdown. Not a date field somewhere in a side panel. A visible remaining-time value that an agent registers at a glance and that sorting can operate on. If a specialist has to open a case to learn it expires tomorrow, the queue design has already failed.

The customer's words, unsummarised, at the top. Summaries strip the phrasing that tells the specialist what kind of reply this needs. "I want my money back today" and "I'd like to query a transaction" describe the same case and require entirely different opening sentences.

Everything Agent has already said. Non-negotiable. The specialist must know precisely what has been promised and what has deliberately not been promised, because the most damaging thing that can happen next is a human contradicting the agent about a deadline or an outcome.

The reason for the handoff, in words. "Verification decision required — second submission after two rejections for cropping" is instruction. "Rule 22" is a lookup the specialist has to perform before they can start.

The evidence pack, structured. For a dispute: transaction object, authentication status, merchant history, the customer's answers in sequence. For verification: outstanding checks, prior rejection reasons, the new document, the case deadline. For a payment trace: reference, rail, corridor, timestamps, beneficiary details as held. Assembled, not scattered across a transcript the specialist has to read backwards.

Account and risk context, live. Status, flags, recent contacts, open cases elsewhere. Live fields, not a snapshot — state may have changed since the escalation fired, and in fraud cases it frequently has.

What has not been done. An explicit line stating that no funds moved, no credential changed, no decision made. Sounds redundant. It is not, because the specialist's first uncertainty is exactly that, and answering it up front saves a check on every single case.

How Inbox surfaces risk before it breaches

A breach is a failure of visibility far more often than a failure of effort. Inbox is built so the risk is legible before the clock runs out rather than reported after.

The SLA clock starts when the customer's message arrived, not when Agent handed over. Any other rule lets a slow escalation hide behind a fast bot, and the resulting numbers are fiction. Conversations approaching their threshold surface visually and can be sorted on, so a specialist opening the queue sees the tightest case first without building a report. Escalations that sit unclaimed past a threshold re-route automatically, because the universal failure mode in a shared queue is the conversation everyone assumes someone else owns.

Two clocks matter and they should be tracked separately. Time-to-human measures whether your routing works. Time-to-resolution measures whether your specialist capacity works. They fail for different reasons and conflating them hides both. Insights should show you both, split by tag, so a rising dispute backlog does not disappear inside a healthy-looking average dragged down by fast decline explanations.

Queue design for deadline-driven work

Four rules, learned the hard way by most teams that have run this.

Separate the deadline queues. Disputes and verification should not share a queue with general enquiries. Mixed queues get worked first-in-first-out by whoever is on shift, and a case with three days left loses to a case with three weeks because the three-week one arrived first.

Sort by remaining time, not arrival time. Obvious in principle, rare in practice, because most helpdesks make arrival-order sorting the default and nobody changes it.

Name an owner per case, not per queue. Deadline work needs a person accountable. Pool ownership means the case with the awkward evidence gap sits there while everyone picks easier ones.

Build in an escalation step before the breach, not at it. A case at 60% of its window with no specialist action should surface to a lead. At 90% it is already too late to do anything but rush, and rushed dispute evidence loses cases.

Configure all of this in Workflows so it runs whether or not anyone is watching, and use side conversations into Slack when a case needs input from risk or payments operations — that keeps the discussion attached to the case rather than scattered across direct messages nobody can retrieve during an audit six months later.

How Copilot helps the specialist be accurate, not fast

Speed is the wrong goal for a specialist reply. A dispute letter or a verification outcome is read closely, sometimes by a regulator, and getting it right matters more than getting it out. Copilot is useful here precisely because it front-loads accuracy.

It drafts from the same grounded context Agent used, with sources cited. The citation is the point. A specialist writing about scheme timelines can check the claim against the actual policy article in one glance instead of relying on memory of a process that changed in March. Most factual errors in financial support replies are not invention; they are confidently remembered old rules.

It holds language consistent on the things that must be consistent. What the company says about dispute timelines, about provisional credit, about verification turnaround — these should read identically across every specialist and every channel, because variation between agents is what complaints are built from. Drafting from a shared grounded source makes consistency the path of least resistance.

It translates in both directions, which in a cross-border fintech is often the difference between a same-day reply and a two-day one routed through whoever speaks Portuguese. The specialist reads the customer's message in their own language and replies in theirs, with the financial terminology handled rather than approximated.

And it surfaces the context that changes the reply: prior contacts about this case, related open cases, whether this customer has complained before. A repeat contact on a deadline case needs a different opening sentence, and a specialist who does not know it is a repeat will write the wrong one.

What Copilot does not do is decide. It drafts; the specialist owns the words and the decision. That division is the same one running through the whole page, applied one layer up.

The audit trail

In most industries the conversation log is a convenience. In financial services it is evidence. Someone will eventually ask what a customer was told, by whom, and when — and the acceptable answers are a record or nothing.

What gets logged

Every inbound message with its channel and timestamp. Every outbound message, with an attributable actor: this human, or Agent under this configuration version. Every retrieval Agent performed, including the ones that returned nothing, because a query that found no policy explains an unhelpful answer better than any post-hoc reconstruction. Every knowledge source cited. Every routing decision and its trigger. Every escalation with its stated reason. Every action taken and, importantly, every bounded action that was not taken because a limit or a boundary blocked it.

That last category is undervalued. A log showing that Agent declined to unlock an account, declined to confirm an identity, declined to promise a refund is the direct evidence that your controls operate. It is what turns a design claim into a demonstrated one.

Alongside it: which configuration was live at the time. Policies change. Ceilings change. Knowledge articles get rewritten. A transcript read two years later is unreadable without knowing which ruleset produced it, and "we think that was before the March change" is not an answer anyone accepts.

Attribution, and why it cannot be fuzzy

Every automated action needs a record that names an actor. "The system" is not an actor. A specific agent under a specific configuration is.

Three reasons. First, incidents. When something goes wrong, the investigation asks who did what and in what order, and an unattributable action stops the investigation dead. Second, complaints. Complaint handling frequently turns on what was communicated and when, and a reconstruction is not evidence. Third, learning. If Agent gave an incorrect explanation about settlement timing, you need to know whether the knowledge article was wrong, the retrieval missed it, or the account data was stale — three completely different fixes, distinguishable only if the retrieval trail was captured at the time.

Answering "who told the customer that, and when"

This question arrives suddenly, usually with a deadline, usually from someone senior. A support platform is fit for a financial product only if the answer takes minutes.

Practically, that means the transcript is searchable by customer, by account, by tag and by date range across channels — the conversation that started on WhatsApp and continued by email has to be one thread, not two records requiring correlation by hand. It means the record includes what was retrieved, not just what was said. It means a transcript can be exported in a form suitable for a complaint file or a regulator, without a screenshotting exercise. And it means the record is immutable in the ways that matter: edits and deletions leave traces, and the timeline cannot be quietly rewritten.

Aftersales is SOC 2 Type II audited and GDPR compliant, and the security and compliance detail sets out what that covers. Your obligations as a regulated firm remain yours; the platform's job is to make the evidence available and defensible, not to assume your responsibilities.

Retention, which is a real decision

Retention is where financial recordkeeping expectations and data-minimisation obligations pull against each other, and the resolution is not one setting. Financial records generally need retaining for years. Personal data should not be kept longer than necessary. Both are true at once.

The workable approach is to decide retention by data class, not by record. Conversation content and decision trail, retained on the financial-records schedule. Identity documents, treated more restrictively — often referenced rather than stored in the support system at all, with the case system of record holding the artefact. Sensitive payment data, never captured in the first place, which is why the field mapping conversation belongs at integration design time rather than after launch. Deletion requests, honoured against the classes where deletion is lawful, with a defensible written basis for the classes retained.

Write it down, get it agreed between compliance and support before go-live, and configure it. Retention decided implicitly by whatever the default was is a decision nobody made and everybody owns.

Using Insights to see patterns, not just cases

The audit trail has a second life as an early-warning system, and this is where the logging discipline pays for itself operationally rather than defensively.

Tag structure is the enabler. Tag decline reasons at the category level, dispute cases by category, verification rejections by document type and defect, payment queries by rail and corridor. Then watch the rates rather than the volumes, because volume moves with growth and rates do not.

The canonical example: a decline reason spiking after a processor change. Overall volume may look normal — a few hundred more contacts in a week, easily absorbed. But payments/decline-issuer as a proportion of card contacts doubles on the Tuesday of the migration. Nobody reported an outage. Approval rates in the payments dashboard look within tolerance because the affected segment is small. The support tag distribution saw it first, because customers experience the failure before any threshold alerts on it. Insights makes that visible if the tags exist, and invisible if they do not.

The same mechanism catches other things worth catching early. A rise in verification rejections for one document type after a vendor updated its checks. A new merchant descriptor generating a burst of unrecognised-transaction reports, which is either a real fraud pattern or a merchant who changed their trading name without telling anyone. A lockout spike concentrated in one app version, which is an engineering bug wearing a support costume.

None of this requires a data team. It requires a tag taxonomy someone owns, a monthly review, and the discipline to look at proportions rather than totals. The guide to measuring resolution rate covers how to define the denominators so the numbers mean something, and the same rigour applies to every rate on this page.

The fintech support stack

In ecommerce, the support stack is a data problem. In fintech it is a data problem plus a permissions problem plus an evidence problem. The customer asks "why was my card declined" and the honest answer lives in three systems, only one of which your agent is allowed to quote from, and whatever you say may be read back to you a year later by a regulator or an ombudsman.

So map the stack twice. Once for where the truth lives. Once for who is allowed to see it, and in what form. Most fintech support teams have done the first and never written down the second, which is why their escalation rules are folklore.

Here is how the layers usually break down.

The ledger or core banking system

This is the bottom of the stack and the only system that is actually right. It holds balances, postings, holds, accruals, interest, fee charges and the double-entry record that backs every number a customer sees in an app.

Everything else — the app, the statement, the notification, the CSV export — is a rendering of the ledger with a delay and an opinion baked in. Support conversations about money are almost always conversations about the gap between the rendering and the ledger. The customer sees a balance that includes a pending authorisation. The ledger sees an available balance and a held amount. Neither is wrong. They are different questions, and the agent has to know which one the customer is actually asking.

What the helpdesk needs from the ledger is narrow and specific: the posting record for a named transaction, its status (pending, posted, reversed, settled), its timestamp with timezone, the balance impact, and any hold or memo-post attached to it. Not the full account. Not the customer's whole transaction history rendered into a sidebar for anyone who opens a ticket.

Be clear about how this connects. There is no shipped core-banking connector. Whether you run Thought Machine, Mambu, a Marqeta-backed program, a bank partner's core, or a ledger you built yourself, the integration is API work: you expose a narrow read endpoint that returns the fields above for a single transaction or account, and Aftersales calls it at runtime from inside the conversation. That is deliberately less convenient than a sync, and it is the right design. Ledger data should never sit at rest in a helpdesk.

What breaks when it is disconnected. The agent answers from the app's view, which is the rendering, and confidently tells a customer a transaction "went through" when it is a memo post that will fall off. Or it says a refund "has been sent" when the posting has not been made. In ecommerce, a wrong shipping date costs you a follow-up. In fintech, a wrong statement about money is a factually incorrect communication to a customer about a regulated product, and in most jurisdictions that is the raw material of a complaint. The second failure is slower and worse: without ledger access the agent has to route every money question to a human, and your escalation rate stays at a level where the AI is not actually reducing anything.

The card processor or payment rails

Above the ledger sits whatever moves the money. Card processing and issuing, ACH or faster-payments rails, wallet top-ups, direct debits. This layer holds authorisation responses, decline codes, network reference numbers, retry state and settlement timing.

Decline codes are the single most valuable field in fintech support and the most consistently misused. A generic "do not honour" tells the customer nothing and tells your agent nothing. But a code indicating insufficient funds, an expired card, a velocity limit, a 3DS challenge that timed out, or an issuer-side block each have completely different answers and completely different next actions. If your agent can read the actual decline reason, a large share of "my payment failed" traffic becomes a one-turn resolution. If it cannot, every one of those becomes a guess.

Stripe is a shipped connector, which matters if you run payments or payouts through it. Charge, refund, dispute and payout state flow in without you building anything. Card issuing platforms, ACH originators and faster-payments rails do not have shipped connectors and reach Aftersales through the API.

The mechanics are worth getting right internally, because agents explain them badly. An authorisation is a reservation, not a movement of money; it drops off on the issuer's schedule. A refund is a new transaction that settles on the network's clock, not yours. A reversal of an authorisation and a refund of a settled charge look identical to the customer and are completely different events. Pending transactions can change amount at settlement, which is why a customer's coffee shows as one figure and posts as another with a tip. Write these mechanisms into knowledge in plain language once, and you eliminate a whole genre of contact.

KYC, identity and onboarding vendors

Onboarding is where fintech support volume concentrates and where the answers are most constrained. Document verification, liveness checks, sanctions and PEP screening, address verification, and the manual review queue that catches everything the automated checks could not decide.

Support needs three things from this layer: the current state of the application, the reason it is in that state, and what the customer can actually do next. That third one is the hard part, because the true reason is often something you are not permitted to disclose. A customer flagged in sanctions screening cannot be told they were flagged in sanctions screening. A customer in enhanced due diligence can be told what documents are outstanding but not the risk logic that triggered the review.

This is the clearest example of why the fintech helpdesk needs a disclosable view, not a raw one. Your identity vendor's API returns a rich verdict object. What should reach the conversation is a status the agent is permitted to communicate, plus a next action. Do the mapping in your integration layer, not in the agent's head. Every KYC and identity vendor is API work.

What breaks when it is disconnected. The agent cannot see whether a document was accepted, so onboarding tickets become ping-pong: the customer uploads, waits, asks, gets told to wait, uploads again. Abandonment at this stage is expensive in a way that support teams rarely get credited for, because a customer who gives up during onboarding never becomes a number in your churn report.

The fraud and risk engine

Rules, scores, velocity checks, device signals, blocks and holds. This layer generates the most sensitive conversations in the entire queue: account frozen, payment blocked, withdrawal held.

What support needs is the fact of the block, the customer-facing category, and the resolution path. What support must never receive is the rule that fired, the score, or the thresholds — not because agents cannot be trusted, but because anything an agent can see can be socially engineered out of them, and anything in a transcript can be read by someone who should not have it. Fraud rule logic leaking through the support channel is a real attack, not a theoretical one.

There is no shipped connector for any risk engine. API, and a deliberately thin payload.

The correct design here is a translation table maintained jointly by risk and support: internal block reason maps to one of a small number of customer-facing messages and one of a small number of next actions. Twelve categories is usually enough. Agent reads the category, never the reason.

The CRM

Salesforce is a shipped connector, which makes this one of the easier layers. In fintech the CRM typically holds relationship context: product holdings, segment, adviser or relationship manager, marketing consent, and in some models the account opening record.

Support needs product holdings above all. An answer about a fee, a rate or an eligibility rule is wrong unless it is scoped to the exact product variant the customer holds, and "our standard fee is" is the phrasing that produces complaints. Sync the holdings; read the rest.

The dispute and chargeback system

Card disputes have their own lifecycle, their own clocks and their own evidence requirements, and they are almost always managed in a system that is not your helpdesk. Filed, evidence submitted, representment, pre-arbitration, arbitration, final outcome. Each stage has a deadline, and missing a deadline forfeits the case regardless of merit.

What the helpdesk needs is the case reference, the current stage, the next deadline, and what evidence is outstanding from the customer. That last field turns dispute support from reactive to proactive: if you know a customer owes you a merchant receipt by Thursday, you can chase on Tuesday.

This is where Inbox deadline views earn their keep. A dispute ticket is not an SLA ticket in the normal sense — nobody cares whether you replied in an hour if the representment window closes on Friday. You want a view that sorts by external deadline, not by first-response clock. API integration, plus a date field on the conversation.

The complaints register

If you are regulated, complaints are not tickets. They are a separate regulated record with its own definition, its own acknowledgement and resolution clocks, its own required disclosures, and in most regimes an obligation to periodically report volumes and outcomes to a regulator.

The mistake almost every fintech makes at least once is running complaints inside the helpdesk as a tag. It half-works until an audit, at which point you discover that "conversation tagged complaint" and "complaint as the regulator defines it" are different sets, and that your acknowledgement timestamps are the timestamp of a reply rather than of a formal acknowledgement.

The right pattern: the helpdesk detects and flags potential complaints, opens the record in the complaints system through the API, stores the reference on the conversation, and stops. The register is the system of record. The helpdesk is where the conversation happens. Detection is a genuinely good use of AI — complaint language is recognisable and humans under queue pressure systematically under-flag it — but the decision that something is a complaint stays with a trained human.

The helpdesk in the middle

Everything above feeds one queue. Email, chat, WhatsApp and SMS land in Inbox, AI and human work sits together, and side conversations go out to Slack when you need a risk analyst's answer without leaving the ticket and without emailing customer data around.

The design principle is the same as in any vertical, but it bites harder here: the helpdesk is a system of resolution, not a system of record. Balance truth lives in the ledger. Identity truth lives with the KYC vendor. Dispute truth lives in the dispute system. Complaint truth lives in the register. The helpdesk reads what it needs at runtime, writes conversations, and stays thin. A thin helpdesk is one you can explain to an auditor in ten minutes.

Two honest caveats, the same two as every vertical. First, Stripe, Salesforce and Slack — alongside Zendesk, Freshdesk, WhatsApp, email and SMS — are the connectors that ship. Ledgers, KYC vendors, risk engines, dispute platforms and complaints registers reach Aftersales through the API, and anyone telling you otherwise is selling you a roadmap as a feature. Second, that API work is smaller than your architecture diagram suggests, because each of these systems needs to contribute three or four fields, not a schema.

Identity, authentication and what the agent may see

In most verticals, identity resolution is about convenience. In fintech it is the control that stops your support channel becoming the easiest way into a customer's account.

Account takeover attempts do not usually start with a technical exploit. They start with a friendly message to support. Someone who has the customer's name, date of birth and last four digits — all of which are obtainable — asks to update a phone number, and if your process is weak, that is the whole attack. Support is the soft edge of every financial product. Design accordingly.

Establish who you are speaking to before you say anything specific

The rule is simple and should be absolute: no account-specific information leaves the system before identity is established. Not the balance. Not whether an account exists. Not "I can see your application is in review". Confirming that an account exists at all is information, and a well-designed process does not leak it.

What it looks like in practice depends on channel.

In-app or authenticated chat is the easy case and the one you should push customers toward. The session is already authenticated, the identity is carried into the conversation, and the agent starts from a known customer. If you run live chat on a logged-in surface, most of this section is already solved for that channel. Make the authenticated path the obvious one.

Email is the hard case. An email address is a weak identifier — it proves control of a mailbox, not ownership of an account. Treat an inbound email from a registered address as a claim of identity, sufficient for general information and not for anything account-specific. The workable pattern is to answer the general part in the open and move the specific part behind an authenticated link: "I can help with that — open the app and tap the message waiting for you" is not a brush-off if the link is genuinely one tap.

Phone and SMS sit in the middle. A number that has been on the account for two years and has passed prior verifications is decent evidence. A number seen for the first time is evidence of nothing. Track the age of the association; it is one of the cheapest risk signals you have.

WhatsApp and social are the weakest and should be scoped to general information and status-only answers until the customer moves to an authenticated channel. Say so in your channel policy rather than leaving each agent to improvise.

Step-up verification for sensitive requests

Not every request needs the same assurance. Build a tiered model and write it down, because the failure mode is an agent making the judgement call under time pressure at 4:50pm on a Friday.

A practical three-tier split:

Tier one — general. Product terms, fee schedules, how a feature works, where to find something in the app. No identity needed. This is where AI resolution should be highest, because there is no account data involved at all.

Tier two — account status. Balance, transaction status, application state, dispute stage. Requires authenticated identity: an authenticated session, or a verified channel plus a successful verification challenge.

Tier three — change or risk. Changing contact details, adding a payee, raising limits, unblocking a card, initiating a withdrawal, closing an account. Requires step-up: a second factor at the moment of the request, ideally pushed through the app, plus in many cases a cooling-off or notification to the previously registered contact details.

That last control deserves emphasis. When a phone number or email is changed, notify the old address. It is a small piece of engineering and it is the single most effective account-takeover control available to a support organisation, because it puts the real customer in the loop at the exact moment the attacker needs them not to be.

Tier three should be human-confirmed or app-confirmed by default. This is not a limitation of AI; it is a design choice about where irreversible actions live. Agent can gather everything, verify the identity signals it has, prepare the change, and hand it to a human or to an in-app confirmation for the final step. The customer experiences one conversation. The control stays intact.

Why the AI agent should read masked data

Here is a principle that is easy to state and surprisingly rare in practice: the AI agent should read the minimum rendering of every field, not the raw one.

It does not need a full card number to tell a customer which card a charge hit. Brand plus last four is sufficient and unambiguous. It does not need a full account number to discuss a transfer; it needs enough to distinguish between the customer's two accounts. It does not need a date of birth to confirm identity if verification happens in a dedicated step that returns a pass or fail rather than the underlying value. It does not need a national identifier at all.

Mask at the integration boundary, not in the prompt. If the API returns the full value and you instruct the model not to repeat it, the full value has already entered the conversation context and, depending on your configuration, your logs. If the API returns •••• 4417, there is nothing to leak. This is the difference between a policy and a control, and auditors know the difference.

The same logic applies to breadth. An agent answering "did my rent payment go out" needs one transaction, not twelve months of statements. Build your read endpoints to answer questions rather than to return objects. A getTransactionStatus(reference) endpoint is safer and easier to reason about than getAccount(id) with a note in the runbook saying please only look at one field.

Data minimisation in transcripts

Conversation transcripts are the least-governed customer data in most financial institutions. They are informal, they are long, they are full of things customers volunteered, and almost nobody treats them as a database subject to the same retention and access controls as the core systems.

Four controls are worth implementing before you scale AI-handled volume, not after.

Redaction on ingress. Pattern-match and strip card numbers, national identifiers and anything resembling a credential the moment a message arrives, before it is stored and before it reaches a model. Redaction that runs at export time is theatre.

Retention with an actual clock. Decide how long conversations live, distinguish between the regulated record you must retain and the operational transcript you need not, and enforce it. "Forever, because storage is cheap" is a defensible engineering position and an indefensible privacy one.

Access control on history. Not every agent needs to read every past conversation. In fintech, browsing history is a real insider-risk vector. Scope it and log it.

A tested deletion path. When a deletion right is exercised, you need to find and remove conversations, not just the core record — while preserving what you are legally required to retain. These two obligations conflict, the resolution is jurisdiction-specific, and the time to work it out is not the day the request arrives. Test it once, document the outcome.

Aftersales is SOC 2 Type II and GDPR-aligned, and the detail your risk team will want sits on the security page rather than in a sales deck. Note what is not claimed: PCI DSS certification is not, and you should not design a workflow that assumes it. If cardholder data would touch the helpdesk under your proposed design, the design is wrong — change the design, do not look for a certificate.

When a customer pastes something they should not have

They will. Regularly. A customer troubleshooting a declined payment will paste their full card number, expiry and CVV into chat because they are trying to be helpful. Another will forward the one-time passcode they just received because an attacker told them to, or because they assume you need it.

You need a defined response, and it has three parts.

Strip it immediately. The redaction rule catches it at ingress so the value never persists in the transcript, the logs, the export, or the model context. This is the control.

Tell the customer plainly, without shaming them. "I've removed that from our conversation — we never need your full card number or a passcode, and you shouldn't share them with anyone, including us." Short, factual, no lecture. Customers who feel foolish stop telling you things, and you want them telling you things.

Treat a shared OTP as a security event, not an oops. A customer who has just received a passcode they did not request and shared it with someone is very possibly mid-social-engineering. The correct path is not "I've deleted that" and carry on. It is an escalation to a human, a check on recent account activity, and in many cases a proactive lock. Write this as an explicit escalation rule in your workflows, triggered on passcode-shaped content, and never leave it to judgement.

There is a fourth part people forget: if a customer pastes a full card number, that card should be treated as potentially exposed even after redaction, because it passed through channels you do not control on the way to you. Whether that means reissue or monitoring is your risk team's call. Make sure they have made it in advance.

Shipped connectors relevant here

Stripe, Salesforce, Slack, Zendesk, Freshdesk, WhatsApp, email, SMS

Everything else

API — ledger, KYC, risk engine, disputes, complaints register

Identity rule

nothing account-specific before identity is established

Step-up required for

contact changes, new payees, limit changes, withdrawals, account closure

Agent reads

masked fields only, scoped to the question asked

Never in the helpdesk

PAN, CVV, credentials, risk scores, fraud rule logic

If a customer shares an OTP

redact, escalate to a human, check account activity

Compliance

SOC 2 Type II, GDPR, HIPAA-ready. PCI DSS is not claimed

Implementation: the first 30 days

This is a runbook, not a project plan. It assumes a regulated or near-regulated business doing somewhere between 2,000 and 20,000 conversations a month, a support team of five to thirty, a compliance function that will need to sign things, and one person who can own the rollout for roughly half their week.

The sequence matters more than the speed, and fintech has one addition to the standard sequence: compliance is involved from week one, not consulted in week four. A rollout that reaches shadow mode before compliance has agreed the authority boundary will stop dead, and it will stop after you have done the work rather than before.

Week 1: connect, import, classify, agree the boundary

Objectives. Every channel lands in one queue. History is searchable. You have a taxonomy that reflects real contact reasons. And you have a written, signed authority boundary describing what an AI agent may and may not do.

Tasks.

Connect email first. Pipe or forward your support address, send test messages, confirm threading, confirm replies leave from the right address with the right disclosures attached. Check SPF and DKIM properly — in financial services, deliverability failures are not just annoying, they are a customer who did not receive a required communication.

Connect chat on your authenticated surface. This is the channel where identity is cheapest, so make it work early and make it prominent.

Connect WhatsApp and SMS if you run them, and start the approval steps on day one because they take longer than you expect. Decide the channel scope now: what tier of request each channel is allowed to serve.

Connect Stripe if you use it, and Salesforce if your CRM holds product holdings. Confirm the sidebar shows what an agent actually needs.

Import history from Zendesk or Freshdesk. Twelve months minimum — week two consumes this data, and in a regulated business the historical record also matters for continuity on open complaints and disputes.

Then the taxonomy. Pull a random sample of 300 recent conversations and read them. Tag each with the real reason. You will end up with something like: payment declined, transaction query, pending versus posted, refund status, transfer not received, card lost or stolen, card activation, account access and login, onboarding document request, application status, KYC review, limit increase, fee query, rate or product terms, statement request, dispute initiation, dispute status, complaint, account closure, and suspected fraud. Twenty categories, give or take. Anything under one percent folds into a neighbour.

Tag every category with a risk level at the same time. Low: general product information. Medium: account status. High: anything involving money movement, identity change, fraud, disputes or complaints. That risk column is the input to every decision you make in weeks three and four, so it is worth arguing about now.

Finally, the authority boundary. Get compliance, risk, support and the rollout owner in one room and produce a document that answers: which categories may an AI agent resolve autonomously, which may it draft for human review, which must it never touch, what identity assurance is required per tier, what it must never disclose, and what triggers mandatory human escalation. Sign it. Version it. This document is the spine of the project and the thing you will hand to an auditor.

Who does what. Ops or engineering connects channels. Your most experienced agent — not the manager — does the taxonomy sample, because they know what customers actually mean. Compliance and risk co-author the boundary. The rollout owner chases signatures.

Done looks like. A test conversation from each channel resolved end to end by a human in Inbox, with the right context in the sidebar. A taxonomy document with volume percentages and a risk column. A signed authority boundary.

Signals you are ready to move on. Nobody is arguing about which categories are high risk. Channel scope is written down. Compliance has read the boundary document rather than been told about it.

Most common mistake. Treating the authority boundary as something to draft after you have seen the AI work. It runs the other way: the boundary tells you what to build. Teams that skip it spend week four renegotiating everything they shipped in week three.

Week 2: build compliance-reviewed knowledge

Objectives. Every high-volume contact reason has a written, current, unambiguous, approved answer. This is the week that determines whether the AI works, and in fintech it is also the week that determines whether it is safe.

The critical difference from other verticals: in fintech the knowledge base is not crowd-sourced. In ecommerce you can mine past transcripts, harvest what good agents said, and ship it. Here, anything the AI will say about a regulated product is a regulated communication, and it needs the same review as any other customer-facing material. Mined transcripts are inputs to that process, never outputs.

Tasks.

Start from approved material, not from macros. You almost certainly already have a library of compliance-approved response templates, product disclosures, terms summaries and letter templates. That is your raw material, and it has already passed review once. Working from it is the difference between a two-week knowledge build and a six-week one.

For each taxonomy category, write the policy as an article in Knowledge: what the rule is, what the exceptions are, what the agent may offer, what it must disclose, and where the boundary sits. Your fee article should cover the fee, when it applies, the variants that are exempt, what happens when a customer disputes it, what you are permitted to waive, and the phrasing to use when you cannot waive it. That last case is where most real traffic lives and most templates are silent.

Mine transcripts for gaps, not for answers. Filter imported history to high-CSAT, short-resolution conversations in your top categories. Read them to discover which questions you have no approved answer for. Where two agents answered the same question differently, you have found a policy gap: decide it, get it approved, write it down. You have now improved the human team as well.

Mark every article with a disclosure requirement where one exists. Some answers cannot be given without an accompanying statement — a risk warning, a rate disclosure, an eligibility caveat. Encode that as part of the article rather than trusting it to be remembered.

Then set confidence thresholds, by category, informed by the risk column. This is a policy decision, not a technical one. Start deliberately conservative and walk them down as transcripts justify it. Being wrong about opening hours is recoverable. Being wrong about whether a payment has settled is a complaint.

Who does what. A senior agent or knowledge owner drafts, with real time allocated — not squeezed between tickets. Product owners approve the substance. Compliance approves the language and records the approval. The rollout owner sets thresholds with the support lead and risk.

Done looks like. Articles covering the categories that make up eighty percent of volume, each with a named owner, an approval record, and a review date. Thresholds documented with reasoning. A tester can ask fifteen realistic questions and get fifteen accurate, appropriately hedged answers.

Signals you are ready to move on. Compliance has signed the articles for at least your top five categories. Nobody on the team can produce a common question the knowledge base cannot answer.

Most common mistake. Importing help-centre pages and declaring the knowledge base done. Public help content is written to reduce contact and is deliberately vague about edge cases, which produces an agent that is confident and wrong on exactly the questions that generate complaints. Write the internal version, and get it approved.

Week 3: shadow mode on one low-risk category

Objectives. The AI drafts answers for one low-risk category without sending them. Humans review every one. Compliance reviews a sample. You fix everything before a customer sees it.

Tasks.

Pick the category. Something low risk, high volume, well-bounded and data-dependent — card activation, statement requests, or general product and fee questions work well. Do not start with payment disputes, and do not start with anything involving a balance.

Turn on shadow mode. The AI produces the response; a human reviews, edits and sends. Meanwhile your agents get faster anyway, because Copilot drafting is genuinely useful even at this stage, and in a multilingual customer base its two-way translation removes a routing constraint immediately.

Review daily. Thirty minutes each morning, one person, a sample of at least thirty drafts. Score each: send as-is, minor edit, major edit, or would have been wrong. Log the reason for anything below send as-is.

Have compliance review a separate weekly sample — and give them their own view rather than a spreadsheet export. What they are checking is different from what the support reviewer checks: not whether the answer was helpful, but whether it was accurate, appropriately caveated, free of implied advice, and consistent with approved language. Expect their first pass to be brutal. That is the point of doing it in shadow mode.

Categorise failures, because the fixes differ. Missing knowledge means write the article. Wrong tone means adjust voice guidance. Missing data means fix the integration. Missing disclosure means the article was incomplete. Correct-but-unhelpful usually means your policy is bad, not your AI. Confident-where-it-should-hedge is the fintech-specific failure and it means your threshold is wrong.

Fix same-day. A week of accumulated problems teaches you nothing.

Who does what. A senior agent with veto power reviews daily. A named compliance reviewer takes the weekly sample. The knowledge owner takes the fixes. The rollout owner tracks send-as-is day over day.

Done looks like. Five consecutive days above eighty percent send-as-is for that category, zero "would have been wrong" in the last three days, and a compliance sign-off on the weekly sample. Only then does it send autonomously — still reviewed daily, just after the fact.

Signals you are ready to move on. The edits compliance makes are stylistic rather than substantive. Your reviewer is bored.

Most common mistake. Reviewing in aggregate. A dashboard showing eighty-four percent accuracy tells you nothing actionable. Reading twenty bad drafts tells you exactly which four articles to rewrite. Every AI rollout that works has someone who reads the conversations.

Week 4: expand, then operationalise

Objectives. Two or three more categories live. SLAs and deadline views configured. Escalation paths agreed and written. The system runs without the rollout owner standing over it.

Tasks.

Expand by risk, not by volume. From your first category, the natural next steps are other low-risk informational types: product terms, rate questions, statement and document requests, app navigation. Then medium-risk read-only status answers once ledger reads are proven. Hold money movement, identity changes, disputes, complaints and anything fraud-adjacent behind the human boundary until you have a month of clean data and a compliance review saying so.

Set SLAs that mean something. With AI absorbing the informational tier, your human SLA can be tighter because humans only see hard things. But add the fintech-specific layer: regulated clocks. Complaint acknowledgement and resolution deadlines, dispute representment windows, statutory response periods for data requests. These are not SLAs in the normal sense — they are external obligations with legal consequences, and they must be visible as such.

Build the views your team will live in. At minimum: escalated from AI, breaching SLA in the next two hours, approaching a regulated deadline, flagged as a potential complaint, dispute awaiting customer evidence, suspected fraud, and reopened. The deadline view is the one that is genuinely different from other verticals: sort by external deadline, show days remaining, and make it the first thing the team sees each morning.

Write the escalation paths down. Rules, not culture. Anything mentioning legal action, a regulator or an ombudsman goes to a human immediately. Any complaint language goes to a human and opens a register record. Any suspected fraud or account takeover signal goes to a human and triggers the account-activity check. Any shared passcode triggers the security path. Any customer who asks twice for a human gets one. Anything below the category confidence threshold goes to a human with a summary, the customer's actual ask, what has been tried, and the AI's best guess attached — an escalation without context wastes the customer's time twice.

Agree vulnerability handling explicitly. Customers in financial difficulty, bereavement, or showing signs of distress or diminished capacity need a human and a different script. Detection can be assisted; handling cannot be automated. Write the signals, write the path.

Schedule the reviews that keep this alive: weekly transcript review, monthly compliance sample, monthly knowledge audit against current policy, quarterly threshold review, and an immediate knowledge update triggered by any product, pricing or regulatory change. Put that trigger in your product launch checklist so support is not the last to know.

Who does what. Support lead owns SLAs and views. Compliance signs the escalation paths and the vulnerability policy. Risk sets the fraud triggers. The rollout owner books every recurring review before handing over, because reviews that are not in a calendar do not happen.

Done looks like. Three or more categories live. Escalation paths in a document everyone has read. A deadline view in daily use. Named owners for knowledge, for transcript review, for the compliance sample and for the monthly resolution rate report. Someone other than the rollout owner can explain the whole system.

Signals you are ready to move on. Nothing. Day 30 is not a finish line — it is the point at which the system is safe to keep improving.

Most common mistake. Declaring victory at day 30. The first month gets you a working system; months two and three get you a good one. The teams still reading transcripts in month six are the ones whose resolution rate keeps climbing and whose complaint volume keeps falling.

Staffing a fintech support team around AI

The uncomfortable conversation first. If an AI agent resolves a meaningful share of your informational contacts end to end, you do not need the same number of tier-one agents. Your team can see this coming and pretending otherwise costs you credibility you will need later.

What actually happens in most regulated businesses is not a layoff. It is a hiring freeze, natural attrition, and redeployment into specialist tiers that were always under-resourced. Fintech support turns over quickly, and the specialist queues — disputes, KYC review, complaints — are almost universally backlogged. Moving people into them is usually the highest-value thing you can do with the capacity AI frees up, and it is a promotion rather than a threat.

The mistake is treating this purely as a cost exercise. The work that remains is harder, more regulated, and more consequential per conversation. Staff it with the same mix you had before and quality falls even as volume does.

The tiers that cannot be automated

Three specialist functions sit permanently outside the automation boundary, and they should be staffed as career destinations rather than overflow.

Dispute handling. Card disputes are part investigation, part evidence assembly, part deadline management. A good dispute handler knows what evidence wins a representment, chases customers for receipts before the window closes, and can tell a weak case from a strong one early enough to save everyone time. AI can prepare the file, surface the deadline, draft the customer chase and summarise the case history. It cannot make the merit judgement or sign the submission.

KYC and enhanced due diligence review. Manual review exists precisely because the automated checks could not decide. The reviewer weighs partial evidence against risk appetite and regulatory obligation, and gets it wrong in both directions if rushed. This role needs training, attestation and a low, protected volume target. Do not measure these people on throughput.

Complaints handling. A regulated complaint requires an investigation, a reasoned outcome, a written response that meets the regime's requirements, and often a redress decision. AI helps with detection, history assembly and drafting the factual sections. The investigation, the fairness judgement and the outcome are human, and in most regimes they need to be demonstrably so.

What happens to tier one

Tier-one fintech work is password resets, card activation, statement requests, fee explanations, app navigation and status checks. It is the tier AI handles best and the tier humans find least rewarding. Removing it changes the job substantially.

What remains is harder per hour and more draining. A queue that is entirely difficult conversations — frozen accounts, failed transfers, customers in financial distress — does not support the occupancy targets you set when half the queue was templated. Plan for lower target occupancy and more recovery time, or you will lose the people you most want to keep.

Build two internal paths deliberately. Some tier-one agents become specialists in the queues above, with a real training pathway. Others move into the roles that did not exist on your org chart two years ago: knowledge owner, conversation designer, and the compliance reviewer described next.

The compliance reviewer in an AI-assisted queue

This is a new role and most teams invent it accidentally, three months late, after an internal audit asks who checks the AI.

Define it properly from the start. The compliance reviewer samples AI-handled conversations against a rubric that is different from the support QA rubric: factual accuracy on regulated matters, presence of required disclosures, absence of anything that reads as advice where you are not authorised to give it, correct handling of vulnerability signals, correct complaint identification, and appropriate hedging where certainty was not available.

Their output is not agent coaching. It is knowledge fixes, threshold changes, escalation-rule changes and, occasionally, a category pulled back behind the human boundary. Give them the authority to do that last one unilaterally. A reviewer who has to build a business case to pause an unsafe category will not pause it.

In a team of ten to thirty this is typically a portion of an existing compliance role plus a standing calendar slot. Above thirty it is a job. Either way, name the person, write the rubric, and keep the review record — because the record is what demonstrates supervision, and demonstrating supervision is most of what an audit is.

Training and attestation

Regulated support roles need documented, repeatable training, and adding AI does not remove that obligation. It adds to it.

Three things belong in your training programme that were not there before. First, how the AI works and where its boundary sits, so agents can explain it to customers and know what has already been said before they pick up an escalation. Second, how to review an AI draft — which is a genuinely different skill from writing one, and the failure mode is rubber-stamping a plausible-sounding answer. Third, what to do when the AI gets it wrong in front of a customer: correct it plainly, do not blame the system, and log it so it gets fixed.

Keep attestation records for the regulated content: who was trained, on what version of which policy, when, and their acknowledgement. When a policy changes, re-attest — and update Knowledge in the same change, so the humans and the AI are never working from different versions of the rules. That last point sounds obvious and is violated constantly.

Quality review sampling for regulated communications

Traditional QA sampled agent tickets and coached. That model breaks when most conversations have no agent. Replace it with three loops that run separately.

AI transcript review, weekly. Sample AI-resolved conversations. Score accuracy, tone, disclosure, policy adherence, and whether escalation should have occurred. Output goes to knowledge and thresholds, not to a person.

Escalation seam review, monthly. Sample handoffs. Was escalation correct and timely? Did the human receive enough context? Did resolution take longer because the handoff was thin? Most genuinely bad fintech support experiences live at this seam, and nobody owns it unless you assign it.

Human conversation review, monthly. Traditional QA on a harder sample, with a rubric that rewards judgement, de-escalation and fair outcomes rather than script adherence. Score fewer conversations, more deeply.

Size your samples so the record is defensible rather than decorative, weight them toward high-risk categories, and rotate reviewers so nobody's blind spots become institutional. Publish the findings internally. Transparency here is what stops agents treating the AI as a black box that is coming for their job.

One metric change is worth making explicitly and early: measure humans on resolution quality and customer outcomes, not tickets closed. When the easy tickets are gone, ticket count measures nothing except how unlucky someone's queue was. Teams that keep a volume leaderboard after adopting AI end up with specialists competing for the easiest escalations, which is the exact opposite of what you built the system for.

Coverage for deadline-driven work

Most support scheduling is built around arrival patterns. Fintech adds a second constraint that has nothing to do with when customers write in: external deadlines that do not care about your rota.

A dispute representment window closes on a date. A complaint acknowledgement is due within a defined period. A regulatory response has a statutory clock. None of these pause for a bank holiday, a sickness absence, or the one person who knows how the dispute platform works being on leave.

Three practical consequences.

First, schedule against deadlines as well as arrivals. Your Inbox deadline view should be someone's named responsibility every single working day, including the awkward ones. Not the team's — a person's.

Second, build redundancy in the specialist tiers. A single dispute handler is a single point of failure with a legal consequence attached. Cross-train at least one backup per specialist queue and rotate them through real cases often enough that the knowledge is current rather than theoretical.

Third, forecast escalations rather than contacts. Your human demand is AI-handled volume multiplied by escalation rate, plus the categories not yet covered, plus the specialist queues which are driven by product and risk events rather than by contact volume at all. Re-forecast monthly while coverage is expanding, and track the specialist queues separately — their volume moves with disputes, onboarding cohorts and policy changes, not with how many people asked about a fee this week.

Coverage, in the end, becomes about capability rather than headcount. Every shift needs someone who can authorise a redress payment, handle a vulnerability disclosure, make a fraud call and meet a deadline. Build rotas against skills, route with workflows, and stop counting seats.

Metrics that matter in fintech support

Fintech support dashboards tend to inherit their metrics from ecommerce, and it goes badly. First response time, average handle time, tickets per agent per day — these were designed for queues where the worst outcome is a slow answer about a parcel. In fintech the worst outcome is a customer locked out of their own money for eleven days, a dispute that misses a scheme deadline, or a confident answer about a fee that turns out to be wrong and becomes a complaint file with your name on it.

The metrics below are the ones that survive contact with a regulated queue. Each has a definition, a formula, a directional sense of what good looks like, and — the part nobody writes into the QBR deck — the specific way it gets gamed once someone's quarterly rating depends on it.

Two hygiene points before the list. First, fix your denominators and your time windows once, write them into a document that a new analyst can read, and never quietly change them mid-year. If you count conversations in January and cases in February, your trendline is an artefact of your own bookkeeping. Second, make Insights the single place the numbers come from. In a regulated environment, a second source of truth is not an inconvenience — it is the thing that makes your board reporting indefensible when someone asks how a figure was derived.

One more framing point that runs through everything here. In fintech, accuracy dominates speed. A support organisation that answers in four hours and is right is worth more than one that answers in forty seconds and is wrong a tenth of the time, because the wrong answers do not stay in the queue. They become complaints, they become remediation exercises, and occasionally they become a regulatory finding. Build your metric set so that it cannot reward speed at the expense of correctness. Most default dashboards do exactly that.

Resolution rate

Definition. The share of conversations that ended with the customer's issue actually handled — question answered correctly, dispute lodged, verification completed, escalation properly routed — without a second attempt by the customer.

Formula. Resolved conversations ÷ total conversations in the period. For autonomous resolution specifically: conversations closed by the AI agent with no human touch and no reopen within a defined window. Fourteen days is a more honest window in fintech than the seven you would use in ecommerce, because money problems have longer tails. A customer who was told their transfer would land in three working days does not reopen on day two.

What good looks like. Directionally, a mature deployment resolves most routine contact without a human: balance and transaction questions, card freeze and unfreeze, statement requests, fee explanations, limit queries, app troubleshooting, status of an in-flight payment. Do not chase a single headline percentage across all volume. A consumer neobank with a heavy app-support mix will have a structurally higher autonomous resolution rate than a lending platform where half the queue is affordability and arrears conversations that should never be fully automated. Compare yourself to yourself, month over month, holding the contact mix roughly constant. The resolution rate playbook covers the instrumentation, including how to define a reopen window that does not flatter you.

How it gets gamed. Three reliable ways. Counting deflection as resolution — the customer was shown a help article, gave up, and emailed instead, producing two conversations and one recorded success. Aggressive auto-close, where any conversation with no customer reply in 24 hours is marked resolved, converting abandonment into achievement. And scope narrowing, where whole categories are excluded from the denominator on the grounds that they are "not really support" — disputes being the classic exclusion, and also the category that matters most. The defences are mechanical: count reopens against the original conversation, treat a follow-up on any channel within 48 hours as a continuation rather than a new ticket, and publish the denominator next to the rate every single time.

Contact rate per active account

Definition. The number of support conversations generated per active account per month.

Formula. Total inbound conversations in a period ÷ active accounts in the same period. Define "active" once and stick to it — logged in during the period, or transacted during the period, are both defensible, but they produce very different numbers and you cannot switch between them.

What good looks like. Lower, and the direction of travel matters more than the level. This is the only metric on the list that connects the support queue to the product that generates it. Every other number measures how well you handle volume; this one measures how much volume you should be handling at all. Break it down by cause: contact rate attributable to failed payments, to onboarding and verification, to card declines, to app errors, to statement and fee questions. Each of those has an owner outside support. Contact rate per active account is the number that lets you hand them the bill with evidence attached.

How it gets gamed. By making contact harder. Burying the help entry point, removing the support address from statements, requiring three self-service steps before a human is reachable. All of these reduce contact rate and all of them increase complaint volume, negative app reviews and, in the worst cases, regulatory attention for poor accessibility of support. Watch contact rate alongside complaint rate. If contacts fall while complaints rise, you have not fixed anything — you have moved the cost into a channel where it is far more expensive.

Deadline compliance on regulated cases

This is the metric that does not exist in other verticals and dominates in this one.

Definition. The share of cases with a hard external deadline — disputes and chargebacks governed by scheme timetables, complaint acknowledgement and final response windows, verification and information requests with a stated response period — that were completed within the deadline.

Formula. Cases completed on or before deadline ÷ total cases with a deadline, computed per case type. Never blend the types. A 98% blended figure can hide a 78% compliance rate on one small, high-risk category, and that category is the one that will be examined.

What good looks like. Effectively 100%, and anything below that should be individually explained rather than averaged. This is a metric where the distribution matters more than the mean. Report the count of breaches, not just the rate, because "three breaches this month" is a sentence an executive can act on and "99.4%" is not. Also track margin: the median number of days between completion and deadline. A team completing everything on the final day is one sick week away from a breach, and the compliance rate will not warn you in advance. Build a deadline view in Inbox that sorts by time remaining rather than time waiting, and make it the first thing the queue opens on.

How it gets gamed. By moving the clock start. If the deadline is measured from when the case was created in the helpdesk rather than from when the customer first raised it, a case that sat in a shared mailbox for four days arrives with four days already spent and a clean-looking timer. Anchor deadlines to the customer's first contact timestamp, wherever that contact landed. The second game is reclassification — recoding a complaint as a "query" so no clock starts at all. Sample and audit the classification monthly; this is the single highest-value audit in a fintech support function.

First-contact accuracy

Most support organisations track first-contact resolution. In fintech it is the wrong target, because it pays people to close conversations rather than to be right.

Definition. The share of first responses that were factually and procedurally correct — correct fee, correct timeline, correct eligibility, correct next step — as judged by a reviewer with access to the underlying systems.

Formula. Correct first responses ÷ sampled first responses. This is a sampled quality metric, not a system-computed one. Fifty to a hundred conversations a month, stratified by contact type and by whether the answer came from a human or from Agent, reviewed against a written rubric.

What good looks like. High and stable, with dispersion by topic that you can explain. Expect fee and pricing questions to score well once knowledge is clean, and expect edge cases around eligibility, arrears and regulated product terms to score worse. That dispersion is your knowledge backlog, ranked. Track accuracy separately for autonomous and human answers — if the AI agent is more accurate than the median human on a topic, that topic should be fully automated, and if it is less accurate, it should be routed away until knowledge improves.

How it gets gamed. By who does the reviewing. If the team reviews its own work, scores drift upward by a few points a quarter and nobody notices. If the rubric is vague — "was the answer helpful?" — everything passes. Use a binary, evidence-based rubric with a named source requirement: an answer is correct if a reviewer can point to the knowledge article or system record that supports it. That requirement alone changes agent behaviour within a fortnight, because it makes citing sources the path of least resistance.

Complaint rate and complaint escalation rate

Two metrics, reported together, because either alone is misleading.

Definition. Complaint rate is the share of conversations that are formally logged as complaints. Complaint escalation rate is the share of those complaints that progress beyond your first-line response — to a second-stage internal review, to an ombudsman or external dispute body, or to a regulator.

Formula. Complaints ÷ total conversations, and escalated complaints ÷ total complaints. Report both as rates and as raw counts.

What good looks like. A stable or slowly rising complaint rate alongside a falling escalation rate is the healthiest pattern, and it is counterintuitive. A rising complaint rate often means your identification is improving — you are catching expressions of dissatisfaction that were previously logged as queries, which is what a good complaint framework is supposed to do. The escalation rate is the quality signal. It says whether your first response actually resolved the grievance or merely acknowledged it. A falling escalation rate with a flat complaint rate is unambiguous improvement.

How it gets gamed. By under-identification, which is both the most common and the most dangerous game in fintech support. A complaint that is never logged as a complaint never breaches a deadline, never escalates, and never appears in your rate. It also never gets fixed, and it shows up eighteen months later in a thematic review. Run a monthly sample of non-complaint conversations specifically hunting for missed complaints, and report the miss rate as its own number. The second game is definitional creep — quietly narrowing what counts as a complaint. Write the definition down, date it, and require sign-off to change it.

Repeat contact rate on the same issue

Definition. The share of resolved issues where the same customer contacts again about the same underlying problem within a defined window.

Formula. Issues with a repeat contact within N days ÷ total resolved issues. Thirty days is a reasonable window for fintech. The hard part is the join: you need to link contacts by issue, not by ticket. Two conversations about the same stuck transfer are one issue contacted twice, and if your tagging cannot express that, this metric will read as noise.

What good looks like. Low and falling, segmented by topic. High repeat contact on a single topic is the loudest available signal that something upstream is broken — an unclear in-app message, a pending status that gives no estimated date, a verification step that fails silently. Repeat contact is also the honest counterweight to resolution rate. A team can push resolution rate up by closing fast; repeat contact is what catches them doing it. Report the two side by side and the gaming largely stops on its own.

How it gets gamed. By treating each contact as a fresh issue. If the second conversation about the same stuck transfer opens a brand new case with no link to the first, the repeat rate is structurally zero and the metric is dead. Enforce linking: any conversation from the same customer within the window about a matching topic should prompt the agent to attach it to the existing case, and Workflows can surface that prompt automatically rather than relying on discipline.

Verification loop completion rate

Identity and document verification is where fintech loses customers silently. They do not complain. They simply stop.

Definition. The share of verification or information-request loops that reach completion — document accepted, identity confirmed, case progressed — rather than expiring, being abandoned or being closed unresolved.

Formula. Completed verification loops ÷ verification loops started, measured per loop type and per attempt number. Also track median attempts to completion, because a 90% completion rate reached on the third attempt is a much worse experience than 85% reached on the first.

What good looks like. High completion with a low attempt count and a short elapsed time. The most useful cut is by failure reason: wrong document type, poor image quality, name mismatch, expired document, customer never responded. The last one is usually the largest bucket and the most fixable — it almost always means the request itself was unclear about exactly what was needed and why. Rewriting the request template moves this metric further than any amount of chasing.

How it gets gamed. By restarting the loop. If a failed verification is closed and a new one opened, each individual loop looks short and the completion rate per loop stays high, while the customer's actual journey is four loops and three weeks. Measure at the customer-journey level, not the loop level, and count attempts explicitly. The second game is counting a loop as complete when the document was received rather than when it was accepted. Received is not complete.

Time to human on high-risk conversations

Definition. For conversations flagged as high risk — vulnerability indicators, suspected fraud, financial hardship, bereavement, complaints, anything where an automated answer is inappropriate — the elapsed time from the risk signal appearing to a qualified human taking ownership.

Formula. Median and 95th percentile of (human ownership timestamp − risk detection timestamp), reported separately per risk category. Use the 95th percentile as the operational target. Medians hide exactly the cases that matter.

What good looks like. Short, and short at the tail. This metric is the honest counterweight to automation ambition. A support organisation that automates aggressively without a fast, reliable path to a human on these conversations is building a liability, not an efficiency. Agent is designed to hand off with full context when it cannot or should not resolve, and the handoff should carry the transcript and the detected signal so the human does not start by asking the customer to repeat a distressing situation. Measure whether that context actually arrives — a fast handoff that loses the history is not a fast handoff.

How it gets gamed. By narrowing the risk definition until few conversations qualify. If only explicit keywords trigger the flag, the metric looks excellent and the real cases — the ones where distress is implied rather than stated — never enter the denominator. Audit the detection layer itself: sample conversations that were not flagged and measure the false negative rate. That number belongs on the same dashboard as the response time, because the response time is meaningless without it.

Cost per resolved conversation

Definition. Fully loaded cost of the support function divided by conversations actually resolved.

Formula. (Salaries and contractor costs + platform and AI fees + tooling + allocated management, QA and compliance review time) ÷ resolved conversations. Fully loaded means fully loaded. In fintech this specifically includes the compliance and second-line review time that support work consumes, which almost every model omits because it sits in another cost centre.

What good looks like. Falling, with a caveat that matters more here than anywhere else: it should fall because automation absorbs routine volume, not because specialists are handling more cases per hour. Dispute and complaint handling has a floor below which quality collapses, and the collapse shows up two quarters later as escalation rate. Segment the number — cost per autonomously resolved conversation and cost per specialist-resolved case are different businesses, and the blended figure conceals the mix shift doing all the work.

How it gets gamed. By moving cost off the numerator. Compliance review time booked to risk, AI spend classified as engineering, contractor hours in a different department, a self-service flow built by the product team whose cost never appears in support's budget. Define the cost basis once with finance, in writing, and reuse it every quarter.

Summary table

Build these ten into one board in Insights, review them weekly, and retire everything else from the executive pack. Ten numbers that mean something beat forty that do not, and in a regulated function the ten you can explain are worth more than the forty you cannot.

Switching from Zendesk, Intercom or a bank-grade legacy suite

Most fintechs reading this already have a helpdesk, and usually a second system alongside it for case management or complaints. Switching costs attention even when it saves money, so the honest framing is not "ours is better" — it is: here is who each incumbent genuinely suits, here is why fintech teams actually leave, and here is what they miss afterwards. If your current setup is working, stay. The runbook in the next section exists for the teams where it is not.

One caveat that applies throughout. Pricing in this market changes constantly. The only figure stated numerically below is Intercom's publicly published $0.99 per Fin resolution. Everything else is described as a shape rather than a price, deliberately. Confirm current figures on each vendor's own site before you put a number in a board paper.

Zendesk

Who it suits. Zendesk is serious enterprise infrastructure and there is a reason it has been the category default for well over a decade. For fintechs it has real strengths: granular permissions, custom objects that can model a dispute or an application as a first-class entity, mature audit configuration, a very broad API surface, and reporting that — once someone has built it — will answer questions simpler tools cannot. If you have a dedicated admin, multiple business units, and process that genuinely needs to be encoded, it fits.

What fintechs actually complain about. The complaints cluster, and they are consistent. The first is conversational AI. Zendesk's automation heritage is rules, triggers and flows, and that shows up as a bot that routes and deflects competently but does not resolve a nuanced question about why a payment is pending. Fintech contact is disproportionately explanatory — customers want to understand a fee, a hold, a decline, a timeline — and that is precisely the category where article deflection performs worst and where a reasoning agent performs best.

The second complaint is configuration sprawl. Trigger chains, automations, business rules, macros and views accumulate over years until nobody can safely change anything. In a regulated environment this calcifies faster than elsewhere, because every rule someone is afraid to touch might be the one implementing a control. Teams describe a six-week lead time to change a routing rule, not because the change is hard but because the change review is.

The third is commercial shape: multi-year commitments, add-on modules for capabilities teams assumed were core, and AI priced separately from seats. Finance teams in particular dislike discovering that the quoted seat price was the floor rather than the total.

What teams lose when they leave. Be honest about this. Reporting depth is the big one — if an analyst has two years of custom dashboards, that work does not port for free. Permission granularity and the audit configuration layer are genuinely strong and should be replicated deliberately rather than assumed. The marketplace breadth means some niche tool you depend on may not have a direct equivalent. And there is institutional familiarity: almost every experienced support hire has used it, and retraining costs about a month of mild friction.

What Aftersales does differently. Less configuration to reach the same operational place. Views, SLAs, assignment, tags and side conversations into Slack exist in Inbox without a build project, and conversation switching is sub-100ms, which affects daily handle time more than any feature list does. Rules still exist in Workflows but carry less load, because Agent reasons over knowledge rather than needing a rule per scenario. Compliance posture is SOC 2 Type II, GDPR and HIPAA-ready, documented on the security page. And Zendesk is a supported integration, which makes parallel running during migration practical rather than theoretical.

Intercom

Who it suits. Intercom is strongest where support and product sit close together. The messenger is excellent, in-app messaging and product tours have no real equivalent in helpdesk-first tools, and for a fintech whose support motion is genuinely part of the app experience — onboarding nudges, feature activation, in-context help — that matters. If a large share of your contact starts inside your own product and is about how to use it, Intercom fits the shape well.

Why the pricing model is awkward here. Fin is priced per resolution — publicly $0.99 per resolution at the time of writing. Per-resolution pricing is defensible in principle: you pay for outcomes rather than for licences. In fintech it creates three specific problems.

The first is case length. A fintech case is rarely one exchange. A dispute spans the initial report, evidence collection, a provisional credit explanation, a scheme update, and an outcome notification — sometimes over weeks. A verification loop spans a request, a rejection, a clarification and a resubmission. Whether that counts as one resolution or five depends entirely on definitional details, and the ambiguity sits on your invoice rather than on the vendor's.

The second is that your bill rises with your operational problems. A payment processor incident, a botched app release, a card scheme outage — each produces a contact spike you did not cause and cannot control, and under per-resolution pricing it arrives twice: once as angry customers, once as an invoice.

The third is forecasting. Seats plus per-resolution charges means budgeting requires forecasting two variables, one of which is volatile. Finance teams in regulated businesses dislike variable cost lines they cannot explain to an audit committee. The broader trade-offs are set out in our comparison of Intercom alternatives.

What teams lose when they leave. The messenger, mainly, and the outbound lifecycle layer. A helpdesk does not replace marketing automation. If you use Intercom for onboarding sequences as well as support, understand that you are unbundling two jobs and may need a second tool for the first. The article editor and help centre presentation are also genuinely well made and teams notice their absence.

What Aftersales does differently. A seat-based starting point from $24 per seat per month, so the bill tracks the size of your team rather than the volume of your incidents. Resolution is the product, not the meter. See pricing for current detail. Stripe is a supported integration, which gives Agent live payment and refund context — the difference between explaining what a pending charge generally means and explaining what this specific charge is doing.

Bank-grade legacy suites

Who they suit. Large regulated institutions, and for good reasons that deserve respect. These platforms — case management suites built for banks, insurers and lenders — are strong exactly where modern helpdesks are weak: immutable audit trails, role-based authority limits with maker-checker controls, retention policies enforced by the system rather than by convention, and evidentiary export that a regulator or an ombudsman will accept without argument. If your operating model requires that a refund above a threshold cannot be issued without a second approver, and that the approval is recorded in a tamper-evident log, these suites already do that. That is not a trivial capability to replace.

Where they struggle. Speed and cost of change. A new intent, a reworded template, a modified routing rule — each is a project with a change board, a vendor professional services engagement, and a release window. Teams routinely describe a quarter to change something that should take an afternoon. Channel coverage is usually narrow: email and phone are handled well, modern chat and messaging channels less so, and WhatsApp frequently not at all without integration work. Conversational AI is typically bolted on or absent. Per-seat costs are high and often bundled into enterprise agreements with long terms. And the user experience burns handle time in a way that is hard to quantify but obvious to anyone who watches an agent work: multiple screens, slow loads, and context that has to be assembled manually.

What teams lose when they leave. The controls, if they are not deliberately rebuilt. This is the honest warning in this section. Do not leave a bank-grade suite without mapping every authority limit, approval chain and retention rule to an explicit equivalent in the new environment, and without agreeing that mapping with your compliance function in writing before you migrate. Teams also lose deep integration into core systems that was expensive to build and will be expensive to rebuild — which is why many fintechs land on a split model, keeping the legacy suite for the narrow set of cases that genuinely need it and moving high-volume conversational support onto something faster.

The pricing column is qualitative on purpose everywhere except the one figure that is publicly published. Vendors rename tiers and reprice AI features regularly; check each vendor's own pricing page before you commit numbers to anything a board will read.

Migration runbook

A fintech helpdesk migration fails in predictable ways, and the failures are more expensive than in other verticals because conversation history is frequently part of a regulatory record rather than just a convenience. The sequence below is ordered as you should actually do it. Assume six to ten weeks end to end for a team of fifteen, most of it parallel running rather than setup — longer than a comparable ecommerce migration, and the extra time is almost entirely compliance sign-off and evidence checking.

1. Get compliance into the room before week one. Not for approval at the end — for scoping at the start. You need three decisions from them in writing: which conversation categories form part of a regulatory record, what your retention obligation is for each, and what constitutes an acceptable evidentiary export. Every subsequent step depends on those answers. Teams that skip this step discover in week seven that the export format they built is not acceptable to their own second line, and they start again.

1. Export conversation history first, and treat the export as evidence. Start it early; API exports are rate-limited and take longer than anyone estimates. Capture conversation bodies, participants, timestamps, internal notes, attachments as files rather than expiring URLs, tags, status history and merge lineage. Then hash the export and record the hash, the date, the operator and the source system. That record is what lets you demonstrate later that the archive was not altered in transit. Store the raw export untouched in durable storage before you transform anything, and keep it after the migration completes — you will need it again.

1. Confirm retention is unbroken across the boundary. This is the step most likely to cause a genuine compliance problem. Your retention clock does not reset because you changed vendors. Decide explicitly whether the legacy system remains the system of record for pre-cutover history (with read-only access retained for the full retention period) or whether the new system becomes the record and the import must therefore be complete and verifiable. Both are defensible. What is not defensible is not having decided, discovering the incumbent contract lapsed, and finding a two-year gap in the archive.

1. Audit and rewrite approved response templates as knowledge articles. Do not port macros one for one. Pull usage counts and you will find a long tail untouched in a year. Keep the tier that covers the bulk of your volume and rewrite it as knowledge articles. This is the most important conceptual shift in the migration. A macro is text a human pastes; a knowledge article is a source an AI agent reasons from and cites. In fintech there is a second dimension: many of those templates carry compliance approval. Track the approval status explicitly as you migrate, route rewritten articles back through the same approval path, and keep a version history so you can answer "what did we tell customers about this in March" without archaeology. One properly written article on a fee structure replaces a dozen macros that each said something slightly different about it — and that inconsistency was already generating complaints.

1. Rebuild deadline views and SLAs deliberately, not by copying. List the views your team actually opens daily; it is usually five or six regardless of how many exist. Rebuild those in Inbox, then build the ones that matter most here: a deadline view sorted by time remaining for each regulated case type, a breach-imminent view, and an escalation view. Re-derive internal SLA targets from current performance rather than inheriting numbers nobody has met since 2023 — but never soften an externally imposed deadline, which is not yours to change. Test each deadline calculation against three real historical cases before you trust it, including one that crossed a weekend and one that crossed a public holiday, because that is where date maths breaks.

1. Preserve case IDs referenced in complaint files. Two separate problems. For case IDs, carry the original reference as a searchable field on every imported conversation. Complaint files, ombudsman correspondence, internal audit findings and customer letters all cite those identifiers, and being unable to retrieve a case by the number a regulator quotes is a bad conversation to have. Do not try to continue the old sequence with new IDs — it creates collisions. For customer identity, deduplicate on your internal account identifier as primary, email and phone as secondary, and run the dedupe on the export rather than after import. Expect a small percentage to need human judgement.

1. Connect systems of record before a single conversation routes. Stripe first if payments sit there. Salesforce if that is your CRM. Email, WhatsApp and SMS channels next. Core banking or ledger systems are an API conversation rather than a shipped connector — scope that work explicitly with engineering and do not assume it. Then verify with real lookups on the awkward cases: partially refunded payments, disputed transactions, closed accounts, customers with multiple products. An AI agent connected to half its data sources produces confidently wrong answers about money, which is meaningfully worse than no agent at all.

1. Run both systems in parallel for two to three weeks. This is the step teams try to skip. Route a defined slice — one channel, or one product line, or general enquiries only — to the new system while the incumbent handles the rest. Two rules make it work. No conversation lives in both places: route at the entry point, never mid-thread. And explicitly exclude open disputes, open complaints and open verification loops from the migrated slice. Those finish where they started. Compare resolution rate, first-contact accuracy, deadline compliance and complaint escalation between the two populations weekly, and only widen the slice at parity or better.

1. Cut over without breaking an open case. The rule is simple and non-negotiable: any case with a live external deadline completes in the system where it started. Freeze new case creation in the incumbent at cutover, let the existing open population run to completion there, and route everything new to the new system. Maintain a joint view during the tail period — a shared spreadsheet is fine, a side conversation into Slack from Inbox is better — so that nobody loses sight of a dispute ageing in a system nobody opens any more. Assign one named person to own the shrinking legacy queue until it reaches zero.

1. Move channels in order of reversibility. Chat widget first: it is the most visible and the easiest to roll back. Do it mid-week, mid-morning, on a low-traffic day, and watch volume for the first hour — zero means the snippet is not loading, double means the old launcher is still present somewhere. Then messaging channels. Email forwarding last, because it has the longest tail: audit the mail admin rather than working from memory, leave the old mailbox receiving and monitored for at least 30 days, update reply-to addresses on statements and transactional notifications, and check SPF and DKIM alignment before cutover rather than after.

1. Decommission on a schedule. Keep the incumbent read-only for a defined period — 90 days is a sensible floor here, and longer if it holds records you have not fully imported. Export again at the end; the first export missed something. Verify the second export against the first before terminating, and check the contract notice period well in advance, because annual agreements commonly require 30 to 60 days' written notice.

Rollback. Define abort conditions before you start, in writing, with a named decision-maker. Sensible triggers: any breach of an external deadline attributable to the new system; first-contact accuracy in the parallel slice materially below baseline for more than three consecutive days; a factually wrong answer about money, fees or eligibility reaching customers more than a handful of times; or a backlog growing for 48 hours straight. Rollback is mechanical if you staged properly — revert the widget snippet, revert email forwarding, stop routing new conversations. The critical rule: never migrate live conversations backwards. Cases already in the new system are worked to completion there, because moving a case mid-flight is exactly how history fractures and a deadline gets lost. Keep the incumbent contract active through the whole parallel period specifically so rollback stays available. Cancelling a month early to save a licence fee is how a manageable setback becomes an incident report.

What fintech support actually costs

Fintech support budgets are usually wrong in the same direction: they count seats and salaries, add a line for AI, and stop. The platform is rarely the largest number, and in a regulated environment it is rarely even the second largest. Here is how to build the model properly, followed by two worked examples. Every figure below is illustrative — round numbers chosen to show how the mechanics behave. They are not quotes, benchmarks, or claims about any vendor's actual pricing.

Seats. The visible cost. Headcount times per-seat licence times twelve. Aftersales starts from $24 per seat per month; see pricing for current plans. The trap is counting only front-line agents. Count everyone who needs access: the ops lead, the QA reviewer, the two compliance analysts who read complaint threads, the fraud team who need conversation context, the product manager who reviews verification failures weekly. In fintech that list typically runs 40 to 60% longer than the front-line headcount, because more functions need read access to conversations than in any other vertical.

AI resolution pricing. Where the model is per-resolution, this is a variable cost driven by contact volume — attractive at low volume, uncomfortable at high volume, because it scales with the exact thing your operation is meant to be reducing. Model it against your worst month, not your average month. For a fintech, the worst month is usually an incident month, and incidents are not evenly distributed.

Compliance review time. The line almost nobody puts in the support budget, because it sits in another cost centre. Complaint review, quality sampling on regulated cases, dispute evidence checking, template approval — all of it is consumed by support volume and all of it should be allocated to the cost of support. Estimate it honestly: hours per month times loaded hourly rate for second-line and compliance staff. For most fintechs this is a material fraction of the front-line salary bill, and once it is visible, the business case for automating routine volume changes shape entirely.

Specialist salaries. Support headcount in fintech is not uniform. A dispute handler who knows scheme rules, a complaints specialist who can write a defensible final response, a fraud-aware agent — these cost materially more than general front-line support and take longer to hire and train. Model your team as a mix of tiers with different loaded costs rather than as an average, because the automation opportunity is concentrated in the cheap tier and the cost is concentrated in the expensive one. Blending them hides the whole argument.

The cost of a breached deadline. Wide variance, rarely computed, occasionally enormous. A missed dispute deadline can mean writing off the disputed amount outright. A missed complaint response window can escalate the matter externally, adding case fees, senior time, and a file that becomes evidence of systemic weakness if it repeats. Estimate it as: (breaches per year × average direct write-off or fee) + (breaches × hours of senior remediation time × loaded rate). Then add a judgement allowance for the pattern risk, because ten breaches is not ten times the problem of one breach — it is a different category of problem.

The cost of a complaint that escalates. Every complaint that moves beyond first-line costs investigation hours, senior review, correspondence drafting, and frequently an external case fee. It also consumes exactly the specialist capacity you are short of. The single largest lever on escalation rate is the quality of the first response, which is why first-contact accuracy is on the metric list and average handle time is not.

Rework from an inaccurate first answer. The quiet one. A wrong answer about a fee or a timeline generates a second contact, sometimes a third, often a complaint, occasionally a remediation exercise where you have to identify every other customer who received the same wrong answer. That last scenario is the real cost of inaccuracy at scale: it is not one bad conversation, it is a population. Estimate rework as (repeat contacts attributable to inaccuracy × fully loaded cost per contact) and treat the remediation tail as a separate risk line.

The three pricing shapes. Seat-based is predictable, scales with headcount, and rewards automation — your bill does not move when an incident triples your volume. Its weakness is that a small team handling enormous volume pays the same as a small team handling little. Per-resolution aligns payment to outcomes and is genuinely cheap at low volume, but it converts operational problems into invoice lines and makes forecasting hard. Hybrid — a seat base plus per-resolution AI charges — combines the floor cost of the first with the unpredictability of the second, and is the shape most incumbents are converging toward.

The fintech-specific problem with per-message and per-resolution pricing is case length. Fintech cases are long and multi-touch by nature. A dispute runs from report through evidence collection through provisional credit through scheme outcome, often across weeks and always across many messages. A verification loop runs request, rejection, clarification, resubmission, acceptance. Under per-message pricing, the long case is straightforwardly expensive. Under per-resolution pricing, the question becomes whether that case is one resolution or five — and the answer depends on definitional details written by the vendor. Neither model is dishonest. Both misalign with the shape of the work, which is why a seat base is easier to defend to a finance team that has to forecast twelve months.

Worked example: a growth-stage neobank. Illustrative figures. Take 200,000 active accounts with a contact rate of 3% per month — 6,000 conversations monthly. The team is twelve front-line agents, three dispute and complaint specialists, and eight additional read-access users across compliance, fraud and product: 23 seats. At $30 per seat per month that is $690 a month, roughly $8,300 a year, and it is flat whether volume is 6,000 or 12,000. Under a per-resolution model at $1 per resolution with 70% autonomous resolution, 4,200 resolutions cost $4,200 a month — about $50,000 a year, plus seat fees on top. Now add the lines most budgets omit: compliance review at 60 hours a month at a $70 loaded rate is roughly $50,000 a year, and three specialists at a premium over general front-line cost add materially more than the platform does under either model. The point is proportion. The platform decision is real, but it is not the biggest number on the page, and a model that ignores compliance review time will pick the wrong platform for the right-looking reason.

Worked example: an incident month. Illustrative figures. Same neobank, but a payment processor outage lasts two days and contact rate for the month jumps from 3% to 7% — 14,000 conversations instead of 6,000. Under a seat-based model, the platform cost is unchanged at $690 for the month; you absorb the volume with autonomous resolution and overtime. Under a per-resolution model at $1 with 70% autonomy, you pay 9,800 × $1 = $9,800 against a normal $4,200 — an extra $5,600 in a month where you were already paying for incident response, goodwill credits and a complaint spike. If you have two such months a year, that is over $11,000 of additional platform cost caused entirely by events you did not create. The mechanic is the whole argument: per-resolution pricing bills you most precisely when your operation is under the most stress and your finance team has the least appetite for a surprise.

The conclusion is not that one model is universally cheaper. It is that you should model your own worst month, with your own contact rate, your own case length distribution, and your own compliance review hours, before you sign anything. Take last year's highest-volume month, apply each vendor's stated model, and compare that figure rather than the annual average. Then add implementation, integration and compliance sign-off time, which are the lines that actually determine whether the year lands on budget. To build that model against your own numbers, start a free trial and run real volume through it for fourteen days.

Risk, compliance and data handling in fintech support

Support in fintech is not a side channel. It is a regulated surface. The moment a customer describes a problem with a payment, asks why an account was frozen, or says the word "complaint", the conversation stops being a chat log and becomes a record that somebody — an auditor, a regulator, a card scheme, a litigator, your own board — may one day read line by line. Most support teams discover this the first time legal asks for "every conversation with this customer between March and June" and the answer takes eleven days to produce.

Start from that assumption and the design decisions get simpler. Treat every transcript as a regulated record from the point of creation, not from the point somebody flags it.

Transcripts are records, not chat history

A support transcript in fintech typically contains four things regulators care about: what the customer was told, when they were told it, by whom, and what happened next. Ordinary chat tooling captures the first and second reasonably well and the third and fourth badly. An AI-native platform changes the risk profile in both directions. It gets better at the first two, because every message is structured and timestamped and the answer is generated from a traceable source rather than a person's memory. It gets worse at the third if you cannot show which system produced which sentence.

So the baseline requirement is attribution. Every message in the thread should carry an unambiguous author: the customer, a named human agent, or the AI agent. Not "the system". Not a shared inbox alias. When the AI agent resolves a conversation end to end, that is a fact you want recorded as plainly as a human resolution, because the question an auditor eventually asks is not "did a robot do this" but "can you show me how this customer was handled and prove that the handling followed your policy".

The second baseline requirement is immutability of the record and mutability of the data inside it. Those sound contradictory. They are not. The sequence of events — message sent, message received, escalation triggered, ticket closed — should be append-only. The personal data inside those messages should be redactable, so you can honour a deletion request without destroying the evidentiary spine of what happened. Platforms that conflate the two force you into a bad choice: keep everything forever, or lose your audit trail.

Data minimisation and masking

The cheapest compliance control in existence is not collecting the data. Every additional field you pull into a support conversation is a field you now have to protect, retain, justify and eventually delete.

In practice that means three habits.

Ask for the minimum identifier that resolves the question. Support agents have a reflex of asking for full details "to be safe". Last four digits plus a transaction date usually locates a payment. A reference number usually locates a transfer. If your workflow demands more than that, the workflow is the problem.

Mask on the way in, not on the way out. Masking at display time still means the raw value hit your storage. Pattern-based detection should run at ingestion, so a sixteen-digit sequence is reduced to its last four before it lands anywhere durable. This is unglamorous plumbing and it is the single highest-value control you can configure.

Keep operational data in the system of record, not in the transcript. The support tool should reference the payment, not copy it. Pull the status live through the Stripe integration or your own API at the moment of the conversation, present what the customer needs, and do not persist a snapshot of the full object into the thread. This shrinks your retention problem enormously.

Card numbers and one-time passcodes

Two categories of data must never enter a support conversation, and they must never enter it for different reasons.

Full card numbers are a PCI DSS scope problem. If a primary account number lands in your support system, that system is arguably in scope for card data environment controls, along with the people who can read it, the backups it sits in, and the vendors who process it. Aftersales holds SOC 2 Type II and supports GDPR and HIPAA-ready deployments; Aftersales does not claim PCI DSS certification, and no support vendor's certificate would relieve you of your own obligations under your acquirer agreement anyway. PCI scope is yours to manage. The only sane position is the simple one: card data does not enter the chat, ever, in any channel, for any reason.

One-time passcodes are a fraud problem. Social engineers impersonate support constantly, and the single most effective script in their playbook is "read me the code we just sent you". If your real agents never ask for a code, the request itself becomes a reliable fraud signal for your customers. If your agents sometimes ask, you have trained your own customer base to be phished. There is no middle position here.

What to do when a customer sends one anyway. They will. Someone will paste a full card number into a chat window at 11pm because they are frustrated and want the problem solved. Have the response pre-built:

1. Detect it at ingestion and redact the value before it persists, keeping only what is needed to reference the conversation.
2. Reply immediately and plainly: the number has been removed, it was not stored, and there is no need to resend it.
3. If the card number reached a channel you do not fully control — an inbound email, an SMS — tell the customer to treat the card as exposed only if your risk policy says so, and log the event.
4. Record the incident in a register. Not as a disciplinary matter; as a frequency metric. If it is happening fifty times a month, your forms and your prompts are inviting it.
5. For one-time passcodes, additionally treat the disclosure as a potential fraud event and follow your step-up authentication path before acting on anything in that conversation.

The last step matters more than people expect. A customer who has just disclosed a passcode may have disclosed it to someone else first. The conversation you are having might be with the attacker.

Vendor due diligence: the questions to actually ask

Procurement questionnaires for AI support tools are mostly theatre. Two hundred questions, most irrelevant, none of which surface the things that will hurt you. Here is the shorter list that matters.

Is our data used to train models? The only acceptable answer for a fintech deployment is no, with a contractual commitment rather than a settings toggle. Ask specifically about sub-processor model providers, because "we don't train on your data" and "our model vendor doesn't train on your data" are different statements.

What is the retention default and can we change it? Ask for the default retention period, the configurable range, whether deletion is soft or hard, how long backups persist after a hard delete, and whether embeddings or derived indexes are deleted along with the source text. That last one catches a lot of vendors.

Who are the sub-processors and how are we notified of changes? You want a published list, a notification period before additions, and a right to object. A vendor who cannot produce a current sub-processor list is not ready for a regulated customer.

Where does data reside and where is it processed? Storage residency and processing residency differ. Inference may happen in a different region from your database. Ask for both, in writing, per component.

Can you delete on request, and how fast? Ask for the mechanism — API, admin action, support ticket — and the committed timeline. Then ask what happens to that data in logs, analytics aggregates and error-tracking systems.

What does your SOC 2 report actually cover? A Type II report has a scope and a period. Read the scope. Read the exceptions. A report that excludes the component you are most worried about is a report about something else. Aftersales publishes its posture on the security page; read it alongside the report rather than instead of it.

What happens at exit? Export format, completeness, timeline, and cost. Any vendor whose export omits AI-generated messages or internal notes is handing you an incomplete regulated record.

Erasure versus retention: how the tension actually resolves

This comes up in every fintech compliance review and is usually described as a contradiction. GDPR gives data subjects a right to erasure. Financial regulation and AML rules require you to retain certain records for years. Both are true. They do not actually conflict, because the right to erasure has never been absolute.

The resolution is scope, not override. Where you have a legal obligation to retain specific records, that obligation is a lawful basis for keeping those specific records — and only those. Everything outside that perimeter is still erasable. So the practical work is drawing the perimeter accurately:

• Retain what is tied to an identified obligation: identity verification evidence, transaction records, complaint files, suspicious activity documentation, and the correspondence that forms part of those files.
• Erase what is not: marketing preferences, general product questions, browsing-adjacent data, conversations with no regulatory nexus, and free-text that contains personal data collected for convenience rather than obligation.

Then implement field-level rather than record-level deletion. A complaint transcript can be retained while the customer's phone number inside it is redacted, if the number is not itself part of the required record. This is where the earlier point about immutable events and mutable data pays off.

Finally, tell the customer the truth in the response. "We have deleted your account data and marketing history. We are required to retain records relating to your identity verification and transaction history for a defined period, after which they will be deleted." That answer is defensible, honest and closes the ticket. Vague answers generate complaints.

Consent and marketing-adjacent messaging

Support conversations drift into marketing more easily than anyone admits. "While I have you — have you seen our new savings product?" is a perfectly natural sentence for a human agent and a potentially unlawful one depending on the customer's consent status and your jurisdiction.

Three rules keep this clean. First, separate service messages from marketing messages at the system level, not the judgement level: a service message answers a question the customer asked; anything else is marketing. Second, check consent state before any non-service content, and make the check a hard gate rather than a suggestion. Third, do not let the AI cross-sell. It is genuinely good at it, which is precisely the risk. Configure the boundary explicitly and test it with adversarial prompts before launch.

Channel matters too. WhatsApp and SMS carry their own consent and template rules layered on top of your regulatory obligations. A message that is fine in an in-product chat may not be fine sent to a mobile number.

Complaint handling records

In most financial services regimes, a complaint is not whatever you decide to call a complaint. It is an expression of dissatisfaction, and the definition is broader than support teams instinctively apply. "This is ridiculous, I've been waiting four days" is a complaint. Treating it as a grumble and moving on is how firms end up with a complaints register that understates reality by an order of magnitude and a regulator who notices.

What you need to be able to evidence: the date received, the substance as the customer expressed it, the categorisation, who handled it, what was investigated, the outcome and reasoning, the date of final response, whether the customer was told about escalation rights, and root cause. AI support helps here in a specific and underrated way — it can apply the complaint definition consistently across every conversation, all day, without the fatigue-driven under-recording that plagues human triage. Configure detection generously and let a human downgrade, rather than the reverse.

Keep complaint conversations linked to the underlying transaction or account event. A complaints register that cannot be joined to the thing complained about is useless for root cause analysis, which is the part regulators increasingly care about most.

What an auditor will ask you to evidence

Practically, expect to produce:

• Access records. Who can read conversations, who granted that access, when it was last reviewed, and how leavers are removed.
• A complete conversation for a named customer, including AI and human messages, internal notes and timestamps, produced in a reasonable timeframe.
• Your retention schedule, with evidence that deletion actually executes rather than being aspirational policy.
• Your masking controls, with evidence of detection working — including the exceptions that got through.
• Change control on AI behaviour. What the agent was permitted to do, when that changed, who approved it, and what it said before and after.
• Escalation and handoff evidence. Which categories never get automated, and proof the rule holds.
• Complaint records, joined to outcomes and root cause.
• Vendor due diligence files, including the SOC 2 report, DPA, sub-processor list and your own assessment.
• Quality assurance sampling of AI-resolved conversations, with reviewer names and findings, tracked over time in reporting.

None of this is exotic. All of it is significantly easier when conversations, resolutions and audit data live in one system rather than four. The firms that struggle at audit time are almost never the ones with bad policies. They are the ones whose evidence is scattered across a chat tool, a ticketing tool, a spreadsheet and somebody's Slack DMs.

Frequently asked questions

Glossary of fintech support terms

Chargeback

A forced reversal of a card payment initiated by the cardholder's issuing bank, not by the merchant. Funds are pulled back from the merchant, usually with a fee attached, and the merchant may contest it. Chargebacks differ from refunds because the merchant does not control the decision or the timing.

Dispute

The broader process a cardholder starts when challenging a transaction, of which a chargeback is one possible stage. Disputes may originate from fraud claims, non-delivery, defective goods or unrecognised descriptors. Support teams see disputes long before finance does, which is why first-contact handling quality strongly affects eventual outcomes.

Representment

The merchant's formal response to a chargeback, submitting evidence that the original transaction was valid and should stand. Compelling representment usually requires delivery confirmation, authentication records, customer communications and terms acceptance. Weak evidence packages lose, so support transcripts are frequently the most valuable artefact available.

Pre-arbitration

A stage after representment where the issuer challenges the merchant's evidence again before the card scheme is asked to rule. Pre-arbitration raises the financial stakes because scheme arbitration fees can exceed the disputed amount. Many merchants accept liability at this point purely on economics rather than merit.

Decline code

The structured response an issuer returns when refusing an authorisation, indicating reasons such as insufficient funds, suspected fraud, expired card or issuer unavailability. Codes vary in specificity and some are deliberately vague to avoid assisting fraudsters. Translating codes into honest customer guidance is core payment support work.

Issuer

The bank or institution that issued the customer's card or account and that ultimately decides whether to approve a transaction. The issuer holds the customer relationship on the funding side, applies its own fraud models, and is the party a merchant cannot see inside. Many declines are issuer decisions merchants cannot override.

Acquirer

The financial institution that holds the merchant account, receives card transactions on the merchant's behalf and settles funds to the merchant. The acquirer also imposes contractual obligations including chargeback thresholds and security requirements. When a merchant is told to reduce dispute ratios, the pressure usually originates with the acquirer.

Processor

The technical provider that routes transaction messages between merchant systems, acquirers and card networks. Processors handle authorisation requests, captures, refunds and reporting, and often bundle tokenisation and fraud tooling. A processor is distinct from an acquirer, though many commercial providers perform both roles under one contract.

Settlement

The movement of funds that actually transfers money from issuing banks to the merchant account, typically batched and delayed by days rather than instant. Settlement timing explains most customer confusion about why an approved payment has not appeared. Authorisation confirms availability; settlement moves value.

Authorisation

The real-time check in which an issuer confirms that funds or credit are available and places a hold on them. Authorisation does not transfer money. Holds can persist visibly on a customer's statement for days, producing frequent support contacts about duplicate or pending charges that are not actually duplicates.

Capture

The step that converts an existing authorisation into a request for actual payment. Merchants often authorise at order time and capture at fulfilment, which creates a gap customers see as a pending charge. Failure to capture within the authorisation window causes the hold to expire and the payment to fail.

Reversal

The cancellation of an authorisation before capture, releasing the hold on the customer's funds. Reversals are faster and cleaner than refunds because no money moved. Issuers do not always release holds immediately on receiving a reversal, which is why customers still report seeing the amount for several days.

Refund

A merchant-initiated return of funds for a settled transaction, processed back along the original payment path. Refunds are voluntary, controlled by the merchant, and typically slower to appear than customers expect because the issuer controls the final posting. Refunds are the preferred outcome compared with a chargeback.

ACH return

A rejection of a bank transfer within the automated clearing house system, returned with a code indicating reasons such as insufficient funds, closed account or unauthorised debit. Returns arrive days after the original transaction appeared successful, which makes them a persistent source of confused and sometimes angry customer contacts.

KYC

Know Your Customer: the process of verifying an individual customer's identity before or during account use, typically through documents, biometric checks and database validation. KYC failures generate enormous support volume because customers experience them as arbitrary rejections while staff are constrained in how much detail they may disclose.

KYB

Know Your Business: the equivalent verification process for corporate customers, covering entity registration, ownership structure, beneficial owners and authorised signatories. KYB is slower and more document-heavy than individual verification, and business customers escalate faster because onboarding delays directly block their ability to trade.

CIP

Customer Identification Program: the formalised minimum set of identifying information a financial institution collects and verifies when opening an account. CIP defines what must be captured and retained, making it one of the clearest examples of a record that retention obligations protect against otherwise valid erasure requests.

AML

Anti-Money Laundering: the framework of controls firms operate to detect and prevent the movement of illicit funds, spanning verification, monitoring, screening and reporting. AML obligations shape what support staff may say, how quickly accounts can be reinstated, and which questions must never receive a direct answer.

Sanctions screening

Checking customers, counterparties and transactions against government and international restricted-party lists. Matches block activity immediately and often cannot be discussed with the customer in detail. Name similarity produces frequent false positives, which is why screening hits require human review rather than automated explanation or resolution.

PEP

Politically Exposed Person: an individual holding or connected to a prominent public position, who therefore presents elevated corruption and bribery risk. PEP classification does not imply wrongdoing but triggers enhanced scrutiny, additional documentation and slower onboarding, which customers frequently experience as unexplained delay and escalate accordingly.

EDD

Enhanced Due Diligence: the deeper investigation applied to higher-risk customers, including source of funds and source of wealth evidence, ownership verification and ongoing review. EDD requests feel intrusive to customers, so the support script explaining why the information is required materially affects completion rates and complaint volume.

SAR

Suspicious Activity Report: a confidential filing made to a financial intelligence unit when a firm suspects illicit activity. The existence of a filing generally cannot be disclosed to the customer. Support teams must therefore have pre-approved wording that neither confirms nor denies, and escalation rules that remove these cases from automation entirely.

Transaction monitoring

Automated analysis of transaction patterns to identify behaviour inconsistent with an expected profile, such as structuring, rapid pass-through or unusual geographies. Alerts feed human investigation queues. Monitoring drives account restrictions that customers experience suddenly, generating urgent inbound contacts requiring careful, limited disclosure.

False positive

An alert that flags legitimate activity as suspicious, whether in fraud scoring, sanctions screening or monitoring. False positives are unavoidable because thresholds trade sensitivity against friction. Their support cost is large and measurable, and reducing it usually requires tuning upstream rules rather than adding more agents downstream.

Step-up authentication

Requiring additional proof of identity before a higher-risk action proceeds, beyond whatever authentication established the session. Step-up is the primary control allowing automated support to handle account-specific requests safely, because it moves the identity decision into a purpose-built system rather than a conversational judgement call.

3-D Secure

An authentication protocol that allows a card issuer to challenge a cardholder during an online payment, shifting fraud liability toward the issuer when applied. Customers encounter it as a redirect or in-app approval. Failed or abandoned challenges are a common and often invisible cause of payment failure.

PCI scope

The set of systems, people and processes that fall under payment card security requirements because they store, process or transmit cardholder data. Scope expands the moment card numbers touch a system. Keeping card data out of support conversations is the cheapest available method of limiting scope.

Tokenisation

Replacing sensitive card or account data with a non-sensitive substitute value that has no exploitable meaning outside the system that issued it. Tokenisation lets support and operations reference a payment instrument without handling real credentials, and is the underlying reason modern support tooling can avoid card data entirely.

Masking

Obscuring part of a sensitive value so that enough remains to identify it without exposing the whole, such as displaying only the final four digits. Effective masking happens at ingestion, before durable storage, rather than at display time when the raw value has already been written somewhere.

Ledger

The authoritative record of balances and movements within a financial system, against which all customer-visible figures should reconcile. Support answers that contradict the ledger create disputes later. Any conversational tooling should read live from the ledger or its API rather than repeating a cached or screenshotted figure.

Reconciliation

The process of matching records between systems — processor reports, bank statements and internal ledgers — to confirm that every movement is accounted for. Reconciliation breaks produce customer-visible discrepancies, and support teams often detect them before finance does because customers report them first.

Complaint register

The formal log of customer complaints, capturing receipt date, substance, categorisation, handler, investigation, outcome, final response date and root cause. Regulators examine registers closely, and under-recording is a common finding. Consistent, generous complaint detection matters more than elegant complaint handling.

Vulnerable customer

A customer whose circumstances — health, bereavement, financial distress, capability or age — make them less able to manage a financial interaction and more susceptible to harm. Identifying vulnerability triggers adjusted handling, slower pacing and human involvement, and is a category that should always be excluded from full automation.

SLA breach

A failure to respond or resolve within a committed service timeframe. In financial services, some timeframes carry regulatory weight rather than merely commercial weight, particularly for complaints and dispute acknowledgements. Breach tracking should distinguish the two, because the consequences of missing them differ substantially.

The bottom line on customer service software for fintech

Here is the honest version.

Aftersales is a strong fit for a fintech support operation where most inbound volume is repetitive, informational and account-specific: where did my payment go, why was my card declined, how long does verification take, how do I update my details, when will the refund land, what does this pending charge mean. That work is high volume, low judgement and enormously time-consuming, and it currently interrupts the people you actually hired for fraud, disputes and compliance. Resolving it end to end with an AI agent that closes conversations rather than deflecting them is the clearest value available, and seat-based pricing means the saving does not evaporate as volume grows the way per-resolution billing does.

It is also a strong fit if your current setup is fragmented — chat in one tool, tickets in another, escalations in Slack, reporting in a spreadsheet. Consolidating into a single queue with proper attribution and an assemblable audit trail is worth doing for compliance reasons alone, before you count a single efficiency gain.

Aftersales is a weak fit in three situations, and it is better to say so now.

First, if your support volume is genuinely low — a few dozen conversations a week, mostly novel — automation will cost you more in configuration and oversight than it returns. Fix the product issues generating the contacts instead.

Second, if the work you want automated is licensed activity, regulated advice, AML adjudication or money movement, the answer is no. Not because the technology cannot produce plausible output, but because plausible output is precisely the hazard. Those decisions need accountable humans, and any vendor telling you otherwise is selling you a future enforcement action.

Third, if your systems of record are proprietary and you have no API surface to expose them, the AI has nothing accurate to answer from. Aftersales connects to Stripe, Salesforce, Shopify, Zendesk, Freshdesk and the major messaging channels out of the box; anything else goes through your own API work. That work is usually worth doing, but it is real engineering time and it belongs in the plan rather than in the optimism.

One last thing worth saying plainly: Aftersales holds SOC 2 Type II and supports GDPR and HIPAA-ready deployments. Aftersales does not hold a financial licence, does not claim PCI DSS certification, and cannot assume your regulatory obligations. No support vendor can. What a good platform does is make your obligations cheaper and faster to meet — through masking, scoped permissions, forced escalation, retention control and evidence you can actually produce when asked.

If that sounds like the right trade, the useful next steps are short. Review the plans and per-seat costs and model them against your current per-resolution or per-agent spend. Start the 14-day trial in draft-only mode and measure agreement rates before anything reaches a customer. And if your compliance team needs specifics — residency, sub-processors, retention, the SOC 2 scope — the security details cover them. Bring compliance in early rather than late.