AI service operations for banks, fintechs & money services
Relay.
Every case, a clear next step.
From WhatsApp and Telegram to web and in-app chat: understand the enquiry, find the right owner and follow the evidence to a verified outcome. Designed for bank customers, merchants, remittance senders and wallet users.
Product concept · Synthetic demo · Production implementation scoped separately
“The customer paid.
Why is the order still pending?”
- 01Payment identifiedMerchant and reference checked
- 02Integration owner suggestedCallback expertise · case authority
- 03Evidence assembledCapture recorded · callback missing
- 04Closure awaits verificationA reply alone does not close the case
Illustration of the proposed workflow, not a live merchant case.
Relay / Omnichannel service
Four ways in.
One accountable case.
WhatsApp, Telegram, web chat and in-app chat belong in the same service workflow. Customers keep the context. Teams keep the owner, evidence, SLA and next action. Email can remain part of the existing helpdesk.
Payment questions, transfer updates and missing-document reminders through a business-owned WhatsApp number.
Connection & identity requirements
Use the WhatsApp Business Platform. Respect consent, approved templates and the applicable messaging window; verify the customer before sharing account details.
Telegram
Bring bot conversations into the case.Receive enquiries through an organization-owned Telegram bot, then hand the conversation to the right service team.
Connection & identity requirements
A Telegram username is not a bank identity. Link a verified customer session before retrieving private records; bot mode and delivery permissions need validation.
Web chat
Help at the point of friction.Offer support on the public website, checkout or merchant portal, with page context and a clear route to a person.
Connection & identity requirements
Separate anonymous product questions from authenticated servicing. Carry only necessary context; do not treat browser-supplied identifiers as proof of access.
In-app chat
Keep service inside the banking or wallet app.Open a case from the transaction the customer is viewing and carry a permission-checked reference into the investigation.
Connection & identity requirements
Connect through an SDK or API adapter. Server-verified identity, session expiry, mobile notifications and per-account authorization are part of the implementation.
Enquiry received
Capture the complaint and issue a case reference. Keep private account information out of the unverified conversation.
Identity checked
The customer signs in through the organization’s app. Link the case only after server-side identity and access checks.
Context continues
The accepted owner receives the conversation, permitted records and original SLA clock. A channel change does not mean starting again.
Proposed channel integration, not connected messaging. Chatwoot documents the underlying inbox channels, mobile chat integration and WhatsApp template rules. Customer-specific identity linking, delivery handling and channel permissions still need implementation.
Built around financial-service workflows
Different institutions.
Specific investigations.
The same service loop can support a bank customer, a merchant or a remittance sender. The records, permissions and department responsible for resolving the problem change.
Banks & digital banks
An account question needs more than a ticket.
“My transfer is debited, but the beneficiary has not received it.”
Trace the account entry and payment-rail reference, check the last confirmed status and keep payment operations accountable for the investigation.
- Other service journeys
- Card disputes, account access, deposit servicing, loan repayment queries and complaint escalation.
- Typical ownership
- Customer service → payments operations / cards / account servicing
What the workflow must respect
Authenticate the customer before account retrieval. Separate card-block, account-change and financial-action approvals from a chat reply.
Fintechs, PSPs & acquirers
Connect the customer story to the payment trail.
“The payment succeeded. Why is the order still pending?”
Bring the merchant reference, processor status and callback history together. Route to integrations, settlements or disputes based on the evidence.
- Other service journeys
- Merchant activation, API integration, refunds, chargebacks, delayed settlements and reconciliation exceptions.
- Typical ownership
- Merchant support → integrations / settlement operations / disputes
What the workflow must respect
Limit access to the correct merchant and provider. Provider acceptance, settlement and customer receipt are different states.
Money service businesses
Keep both ends of a money transfer in view.
“My family has not received the transfer. Who is following up?”
Connect the transfer reference, corridor, payout partner and delivery evidence. Give remittance operations ownership and retain a clear next-update time.
- Other service journeys
- Money-transfer operators, remittance providers and exchange houses: failed payouts, beneficiary corrections, FX quote expiry, cancellation requests and compliance-review handoffs.
- Typical ownership
- Service desk → remittance operations / FX desk / compliance team
What the workflow must respect
Never retry a transfer or change a beneficiary from a message alone. A compliance hold needs authorized review and an approved customer explanation, not an AI release decision.
Wallets & e-money providers
Explain the balance without guessing at it.
“My cash-out failed, but my wallet balance is lower.”
Compare the wallet entry, cash-out request and partner response. Keep uncertain debits open for reconciliation before considering a reversal or retry.
- Other service journeys
- Top-up delays, limits, onboarding verification, cash-in/cash-out, account recovery and agent-network enquiries.
- Typical ownership
- Wallet support → ledger operations / payout partner / identity team
What the workflow must respect
Use a governed ledger source and customer permissions. AI may assemble evidence and draft an explanation; it does not create a balance adjustment.
01 / The operating loop
From first enquiry to
a case you can close.
A busy inbox can hide the real problem: a complaint has moved between teams, but nobody owns the next step. The product brings identity, evidence, ownership and follow-through into one workflow.
- 01
Intake
Identify the customer, account and transaction. Capture what actually went wrong.
- 02
Understand
Suggest an issue type, request missing details and show uncertainty.
- 03
Route
Find an authorized owner with the right skills and available capacity.
- 04
Investigate
Assemble a sourced payment timeline and separate facts from assumptions.
- 05
Resolve
Review the response, authorize any action and verify its effect.
- 06
Learn
Confirm closure, collect feedback and review recurring failure patterns.
02 / Try the product
Work a complaint.
See the decisions.
Choose a bank, fintech or money-services problem and a contact channel, then test the investigation. Every AI suggestion, person and record below is simulated. Nothing is sent and no money moves.
Verify the signed-in customer before retrieving private account records. Anonymous chat can answer general questions.
Synthetic channel selection. No messages are delivered. Identity linking is assumed only for the authorized demo state.Sample case ready for intake.
The customer’s enquiry
Capture the problem once.
“Our customer paid, but order 1042 is still pending. Can you check what happened?”
- Customer / account
- Northstar Store · synthetic
- Transaction reference
- DEMO-PAY-1042
- Channel
- Web chat → shared case
- Identity check
- Verified for this demo merchant
In a live system, identity and access checks must run before payment details are exposed. Do not enter real customer or account data into this demo.
AI-assisted triage
Make the issue explicit.
- Suggested issue
- Payment captured, order pending
- Priority rationale
- Checkout fulfilment is blocked
- Required evidence
- Payment capture + merchant callback log
- Do not assume
- A recorded capture means the order was fulfilled
A structured summary and a request for missing evidence. The issue classification is a suggestion that the operator can correct.
Ownership, with a reason
Get it to the person who can act.
Authorized for this merchant, trained on the demo PSP and available for callback investigations.
Settlement operations can inspect payouts, but does not own this callback integration. Risk review is not indicated by the available evidence.
Routing is complete only when an accountable owner accepts. When nobody qualifies, the case remains in an exception queue with an escalation clock.
A sourced investigation
Show what is known. Keep the gap visible.
- 09:41Provider record: payment capturedDemo provider API · synthetic timestamp
- 09:42Merchant callback log: acknowledgement missingDemo investigation record · synthetic timestamp
- 09:44Next check: confirm order state before any retryApproved sample runbook · operator review required
If a provider times out, the payment outcome remains unknown. Retrying a money-changing action requires reconciliation and duplicate protection.
Review before responding
A useful reply, with the next step.
The demo provider records a captured payment, while the merchant callback acknowledgement is missing. Our integration owner is checking the order state before any controlled retry. We will update this case after that check; fulfilment is not yet confirmed.
This button changes the demo only. It does not send a message, refund a payment or close the case.
Resolution and feedback
Close the loop, then learn.
Closure needs an updated merchant order state and confirmation that the original fulfilment problem is resolved.
Customer confirmation and issue-specific evidence are recorded separately from satisfaction. A returning complaint reopens or links to this case.
No satisfaction score is invented. CSAT responses and later relationship NPS would be collected separately.
Operations dashboard / Product feature
See the pattern.
Know who needs to act.
Which problems keep coming back? Which department owns the backlog? Where are SLAs slipping, and when do contacts peak? Give support leads a view of customer pain and the work behind it.
Filter the same case cohort across every chart. Ownership is different from the department that caused an issue.
Enable JavaScript to explore the synthetic dashboard. No live metrics are loaded.
No sample cases in this view.
Try a wider creation window, another department or another channel. No cases does not establish perfect SLA performance.
Where conversations start
One originating channel per case, even when the conversation later moves. Select a channel to filter every chart. These are case counts, not message-delivery statistics.
| Channel | Cases | Open | Replies in target / eligible |
|---|---|---|---|
| Channel data appears when the demo loads. | |||
What customers are facing
One primary issue type per case. Counts and share of the selected cohort.
Where the work sits
Accepted owner at snapshot. Select a department to inspect its issue mix and SLA exposure.
| Department | Open | Overdue | Total |
|---|---|---|---|
| Department data appears when the demo loads. | |||
When contacts arrive
Case-created hour in GST (UTC+4), grouped across the selected days. Raw case counts, not a staffing forecast.
Peak-hour observation appears when the demo loads.
Ageing and repeat complaints
Open-case age continues while waiting for a provider. Repeat flags are sample labels, not an AI diagnosis.
CSAT and NPS: no responses collected in this sample. Connect feedback separately and report response coverage.
Cases that need attention
Overdue first replies, overdue or near-deadline resolution, and missing ownership. Sorted by resolution exposure, then age.
| Case / customer issue | Owner | Age | Attention reason |
|---|---|---|---|
| Attention queue appears when the demo loads. | |||
What this view tells the team
- Observations appear after loading the synthetic cohort.
These are descriptive sample observations. Root cause needs investigation; changing staffing, provider policy or routing needs an operational decision.
Metric definitions, SLA clock and sample limitations
The window filters cases by creation time relative to the fixed snapshot. Backlog and age are measured at that snapshot within the selected cohort, so older cases outside the window are excluded. A production backlog view should also offer an unrestricted queue.
Each sample case has a 60-minute first-response target and its own resolution target. Targets use elapsed wall-clock time, with no business-hours calendar or waiting pause. First-response performance includes answered cases and unanswered cases already past their response deadline; unanswered cases still within target are excluded and reported. Resolution overdue means an open case past its resolution deadline. At risk means an open case has consumed at least 75% of that time.
Channel attribution uses the channel that opened the case. A later handoff does not create another case or reset its SLA. Identity linking and cross-channel deduplication are production integration requirements, not inferred from a display name.
Counts are derived from fixed synthetic fixtures. There is no connection to a helpdesk, provider or AI model. In production, targets, working hours, holidays, pause rules, reopened cases, department ownership and event definitions must be agreed and auditable.
Operations dashboard & learning / API integration
Bring Relay into
the systems you use.
Feed case events from your helpdesk, CRM, banking platform or wallet. Bring the same operational view into your internal portal or BI tool. Send ownership and SLA alerts back to the teams that need to act.
Authorized case references, events and evidence pointers.
Validate the event, retain its audit trail and update the reporting view.
Read summaries and receive signed notifications.
Three integration surfaces
POST /v1/case-events- Receive case creation, contact, accepted-owner and verified-resolution events. An accepted request means queued for processing, not a completed investigation.
GET /v1/operations/summary- Retrieve workload and SLA metrics by creation window, originating channel and department, with a snapshot time and processing watermark.
- Outbound webhooks
- Notify your systems when ownership changes, an SLA is approaching or breached, or a resolution is verified. Receivers verify the signature and deduplicate event IDs.
Design contract v0.1 · No deployed endpoint, API keys or webhook delivery. The example uses the dashboard’s synthetic seven-day cohort.
GET /v1/operations/summary?window=7d&channel=all
{
"snapshotAt": "2026-10-23T12:00:00Z",
"timezone": "Asia/Dubai",
"cohortBasis": "case_created_at",
"channelAttribution": "originating_channel",
"counts": {
"cases": 18,
"open": 8,
"resolutionOverdue": 3,
"firstReplyWithinTarget": 13,
"firstReplyEligible": 17
}
}13 of 17 eligible first replies met the sample target: 76%. Cases not yet due are excluded from that denominator.
Identity, permissions and data boundaries
Use server-side service credentials with separate event-write and report-read permissions. Derive tenant access from the credential, not a customer-supplied identifier. Send opaque references and approved evidence pointers; keep full account records and sensitive review details in their authorized source systems.
Retries, failures and freshness
Idempotency keys prevent duplicate ingestion; reused keys with different payloads return a conflict. Validate events and their authority, surface invalid transitions and handle out-of-order records. Publish a processing watermark so a delayed projection cannot look like a current dashboard. Webhook delivery needs signed timestamps, retry policy, deduplication and failed-delivery review.
Learning stays reviewable
Use reporting data to investigate repeated complaints, misroutes and missing answers. A proposed improvement should link to case evidence and enter a review queue. Publishing knowledge, changing routing or adjusting policy requires an accountable reviewer; the reporting API does not silently retrain a model or change financial decisions.
03 / Product scope
Six modules.
One accountable case.
These are the proposed product capabilities. The demo illustrates six complaint types; integrations, AI models and production controls still need implementation.
One case, across channels
WhatsApp, Telegram, web chat and in-app chat feed a shared case record, with email retained where needed. Link channels after identity verification, preserve the original SLA clock and track delivery failures separately from case resolution.
Explainable owner selection
Suggest a team or person using provider expertise, service ownership, permissions, language, capacity and SLA. Record who accepted the case and why a transfer was necessary.
An investigation with receipts
Read authorized payment records, callbacks, refund references and settlement evidence. Link each finding to its source and timestamp; leave unknown states visibly unresolved.
A useful agent assist
Draft a concise explanation and next steps from approved knowledge and case evidence. Show the CSR what supports the answer and what still needs checking.
Controlled resolution
Separate a suggested action from approval, execution and verified effect. Refunds, credits and payment retries require explicit authority and duplicate-action protection.
Operations dashboard, learning & APIs
Connect case events through an API and expose dashboard summaries to your existing tools. Show customer issue types, channel and department ownership, SLA exposure, peak contact hours and ageing cases. Surface repeat issues, misroutes and knowledge gaps for review. Give customer success managers account-level themes; keep policy and knowledge changes under human ownership.
04 / The buying decision
Compare the whole
support operation.
The established tools already do AI and routing. A tailored offering has to earn its place through your provider coverage, investigation controls, operating ownership and deployment requirements.
Official documentation reviewed 23 October 2026. Published prices exclude applicable taxes, channel fees, implementation and other add-ons. Verify the selected edition and contract before buying.
Intercom + Fin
A mature helpdesk with AI conversations and connected procedures.
- What it already does
- Workflows, routing, external data connectors and human approval are already available, with edition and access differences.
- Published commercial model
- Standard annual seat pricing: USD 29 / 85 / 132 per month. Fin: USD 0.99 per outcome. Promotions and add-ons are separate.
Edition limits & purchase test
An outcome can include an intentional Procedure handoff. It is not always a customer-confirmed resolution. Confirm the external-helpdesk contract and Procedure access.
Ask in the demo: Can the procedure distinguish provider acceptance from customer receipt, pause for the authorized owner, and retain the full investigation?
Zendesk AI agents + Copilot
A broad service operation with structured tickets, skills and SLAs.
- What it already does
- Intelligent triage, omnichannel routing and external actions cover much of this lifecycle. Skills, Copilot and workflow entitlements vary by plan.
- Published commercial model
- Request a current regional quote for seats, Copilot and verified-resolution allowance. A USD rate was not confirmed in this review.
Edition limits & purchase test
Current resolution tiers distinguish assisted escalation, contained resolution and verified resolution. Only the verified tier consumes the documented resolution allowance.
Ask in the demo: Does the chosen edition route by provider authority and SLA, preserve source evidence, and expose a case that remains unresolved?
Freshdesk / Omni + Freddy
Teams choosing between email-led support and a messaging helpdesk.
- What it already does
- AI workflows, REST/MCP actions, human handoff and routing are documented. Freshdesk and Freshdesk Omni are different packages.
- Published commercial model
- Annual monthly seat equivalents: Freshdesk $19 / $55 / $89; Omni $29 / $79 / $119. Copilot $29/agent; AI $49/100 sessions.
Edition limits & purchase test
The 500 included AI sessions are a one-time allowance. Chat and email session windows differ; connector and MCP action charges can also apply. Confirm account currency.
Ask in the demo: Does a complaint spanning chat, email and a provider action keep its context, and how many sessions and billable actions does it use?
Chatwoot + Captain
A configurable inbox with cloud and self-hosted deployment choices.
- What it already does
- Captain supports semantic triage, scenarios and tools. Its current catalog includes Stripe payment, invoice and subscription lookups.
- Published commercial model
- Cloud displays $19 / $39 / $99 per agent/month, with 300 / 500 / 800 account AI credits. Extra credits: $20/1,000. Confirm currency and term.
Edition limits & purchase test
Credits are AI replies, requests or actions, not resolved cases. Community self-hosting excludes Captain and custom branding; paid-edition and rebranding rights need validation.
Ask in the demo: Which required providers are supported, what identity checks precede a lookup, and which branding, SSO and tool capabilities need a paid agreement?
Compare the same complaint mix, staffing, channels and integrations. Include human handoffs, unresolved backlog and quality review in cost per verified resolved case.
Configure an existing tool when…
Its workflow, provider access and deployment model meet your needs. A focused integration and better runbooks may solve the problem with less custom software.
Consider a tailored offering when…
You need a branded experience, specific customer and provider controls, deployment choices or an operating workflow the selected edition cannot support economically. Validate that gap in discovery.
05 / Measure the outcome
Fewer transfers.
Better investigations.
A testable business case.
Set a baseline before promising improvement. Compare like-for-like complaint cohorts and retain unresolved cases in reporting. Faster replies are useful only when answer quality and resolution hold up.
Routing quality
First-owner correctness, avoidable reassignment rate and cases with no accepted owner. Review a consistent sample.
Resolution quality
Median and p90 time to verified resolution, seven-day reopen rate and unsupported-answer rate. Keep provider waiting time visible.
CSAT
For a five-point survey: ratings 4–5 divided by valid responses. Show response count and response rate, alongside the distribution.
Relationship NPS
Percentage of 9–10 promoters minus percentage of 0–6 detractors. Survey a defined customer cohort; keep it separate from case CSAT.
Metric definitions: CSAT guidance · Net Promoter System. These are proposed measurements, not achieved results.
Planning calculator / illustrative assumptions
What could fewer handling minutes mean?
Estimate gross agent capacity released. This does not predict cost savings, headcount reductions, CSAT or NPS.
Illustrative gross capacity released per month.
1,000 cases × (12 − 9) minutes ÷ 60Subtract integration, QA and ongoing operating effort from any financial business case.
06 / From concept to operation
Choose the boundary.
Prove one workflow.
Start with a named complaint type and provider, then expand against measured acceptance criteria. Production readiness is a delivery milestone, not a property of this preview.
Before a pilot, test stale payment evidence, refund timeouts, tenant boundaries and escalation. Use the twelve-case AI payment-support evaluation pack to record expected answers and prohibited actions. The pack uses synthetic cases; it does not report measured Relay performance or establish production readiness.
Extend your helpdesk
Retain the inbox and connect the banking, money-services or merchant investigation workflow. Validate APIs, permissions, edition costs and the system of record.
Customer-controlled deployment
Scope a dedicated environment, branding and approved model access. Agree data residency, tenant isolation, retention, upgrades and support responsibilities.
Managed implementation
A proposed implementation and operations engagement. Define the support window, recovery objectives, model monitoring and third-party usage charges in the agreement.
- 01
Discover
Map complaint classes, provider truth, ownership, current costs and baseline metrics.
- 02
Configure & integrate
Build identity, read-only evidence, approved knowledge and routing. Validate license and branding rights.
- 03
Pilot with controls
Test missing evidence, access denial, no owner, timeouts, duplicates, human approval and reopened complaints.
- 04
Operate & improve
Accept against agreed evidence, assign support ownership and monitor quality, cost and durable resolution.
07 / Before you decide
Practical questions.
What is Relay?
Relay is a proposed white-label AI service operations product for banks, fintechs, PSPs, money service businesses and wallet providers. It brings conversations, verified customer context, specialist ownership, investigation evidence and operational reporting into one service loop. This page demonstrates the workflow using synthetic data.
Can customers use WhatsApp, Telegram, our website and our app?
All four are included in the proposed channel scope. WhatsApp uses a business-owned account, Telegram uses an organization-owned bot, web chat uses a widget and in-app chat needs an SDK or API integration. Connecting a channel does not verify a bank customer. Cross-channel records are linked only after identity and access checks. This demo does not connect or send to these services.
Does it cover remittance providers and exchange houses?
Yes, the proposed money-services workflows cover delayed transfers, beneficiary enquiries, payout exceptions, FX quote questions and compliance-review handoffs. Relay can assemble approved evidence and route the case to remittance operations, the FX desk or compliance. It does not approve a transfer, release a compliance hold or change a beneficiary on its own.
Is Relay also a core banking system?
Relay is the service and investigation layer. Railspan’s core banking module covers customer accounts, savings, loans and accounting using an Apache Fineract foundation. A scoped connector would bring authorized records into Relay; the two are not a pre-integrated production system.
Is this ready to connect to my live payment systems?
No. This page contains an interactive prototype and a proposed delivery scope. The demonstration uses fixed synthetic cases and simulated AI output. Production connectors, model evaluation, tenancy controls and operational readiness must be implemented and tested for your environment.
Can it work with our existing helpdesk?
That is a proposed deployment option. Start by checking the existing tool’s APIs, identity model, permissions, routing features and commercial terms. A focused integration may be a better fit than replacing the helpdesk.
What does white-label mean here?
A customer-branded experience with configured workflows, knowledge and integrations. It does not mean removing upstream notices or receiving every enterprise feature for free. The implementation scope must identify software licenses, paid editions, trademarks and distribution rights.
Will the AI issue refunds or move money?
This prototype does neither. A future implementation must treat financial actions separately from conversation handling: verified identity, policy eligibility, authorized approval, idempotent execution and independent outcome checks. An uncertain provider result stays open for reconciliation.
Will this improve CSAT and NPS?
That is a hypothesis to test. Measure a baseline and compare similar complaint cohorts during a pilot. Report resolution quality, unanswered cases, survey response rates and cost alongside speed. No measured uplift is claimed here.
What would an initial engagement include?
A complaint and provider map, current-tool assessment, a scoped prototype, integration design and pilot acceptance criteria. The implementation and support quote follows that scope; there is no published fixed subscription or guaranteed delivery time.
Start with the case that keeps coming back.
Bring a support workflow.
Let’s map the product.
Discuss your complaint types, providers, current tools and the outcome your team needs to improve.