FinTech · Playbook
The fintech playbook. Built in the builder, decided by your ledger.
Ten journeys, each drawn below as it runs. The decision comes from your ledger, your credit engine or criteria you set; the journey carries it. Aims are targets to agree in the pilot, not results.
PLAYBOOKS · 01Illustrative journey
Fund the wallet within forty-eight hours of KYC.
A verified wallet with no top-up after forty-eight hours gets one push that opens Add money, and one WhatsApp three days later if money still has not landed; the journey stops the moment it does.
- Decides
- your ledger's KYC and top-up events.
- Aim
- more wallets funded in the first week.
Built in the journey builder
Fund the wallet within forty-eight hours of KYCFINTECHStarts when your ledger says verified; stops the moment money lands.
Campaign Start · APIKYC verified, wallet empty (from your ledger)
Wait TimeWait 48 hours
Event CheckTop-up seen?
Yes
No
End
Check Channel ConsentCheck push consent
Push + InboxPush with the Add money deep link
Event CheckTopped up within three days?
Yes
No
End
Message · WhatsAppOne WhatsApp, then silence
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- more wallets funded in the first week.
- Trigger
- KYC verified, wallet empty (your ledger)
- Events and identifiers
- KYC verified, wallet empty (your ledger). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- None beyond the platform's own records: the contact, its consent, and the delivery record.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- top-up seen? stop · topped up within three days? stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- more wallets funded in the first week. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 02Illustrative journey
Offer the savings pocket the day the salary lands.
A salary credit into the wallet asks your ledger whether the user already holds a pocket, then sends one WhatsApp with Open a pocket or Not now; a tap goes to your system to open it.
- Decides
- your product rules and what your ledger holds.
- Aim
- pockets opened without a campaign.
Built in the journey builder
Offer the savings pocket the day the salary landsFINTECHYour ledger confirms the pocket is not held before anything is offered.
Campaign Start · APISalary credit into the wallet (your ledger)
API CallPocket held? Ask your ledger
Not held, eligible
Already held
WhatsApp FlowWhatsApp: Open a pocket / Not now
Open a pocket
Not now
No reply
API CallYour system opens the pocket
Message · WhatsAppConfirmation
End
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- pockets opened without a campaign.
- Trigger
- salary credit into the wallet (your ledger)
- Events and identifiers
- salary credit into the wallet (your ledger). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- pocket held? (your ledger) · your system opens it. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- no tap: silence. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- pockets opened without a campaign. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 03Illustrative journey
Raise the limit the day the third instalment clears.
A third instalment paid on time asks your credit engine whether a higher limit is available, then sends one WhatsApp with Raise my limit or Keep it; a tap goes to your system to apply it.
- Decides
- your credit engine.
- Aim
- limits raised without a call, only where your engine agrees.
Built in the journey builder
Raise the limit the day the third instalment clearsFINTECHYour credit engine answers before anyone is offered anything.
Campaign Start · APIThird instalment paid on time (your ledger)
API CallHigher limit? Ask your credit engine
Yes, new limit set
No change
WhatsApp FlowWhatsApp: Raise my limit / Keep it
Raise my limit
Keep it
No reply
API CallYour system applies the new limit
Message · WhatsAppConfirmation
End
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- limits raised without a call, only where your engine agrees.
- Trigger
- third instalment paid on time (your ledger)
- Events and identifiers
- third instalment paid on time (your ledger). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- higher limit? (your credit engine) · your system applies it. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- no: nothing sent. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- limits raised without a call, only where your engine agrees. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 04Illustrative journey
Turn an unused credit limit into a first draw.
A limit approved and untouched for thirty days checks with your credit engine that it is still live, sends one Story on three ways to use it, and one WhatsApp with a use case if they read it.
- Decides
- your credit engine and your segment definition.
- Aim
- first draws on limits that were sitting idle.
Built in the journey builder
Turn an unused credit limit into a first drawFINTECHA check with your credit engine, then one Story, then a WhatsApp only if they read it.
Segment EntryLimit approved, no draw in 30 days
API CallLimit still live? Ask your credit engine
StoryStory in the app: three ways to use it
Event CheckRead?
Yes
No
WhatsApp FlowWhatsApp: one use case, tap to pay
Tapped
No reply
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- first draws on limits that were sitting idle.
- Trigger
- segment entry: limit approved, no draw in 30 days
- Events and identifiers
- segment entry: limit approved, no draw in 30 days. Segment membership is recomputed from the contact's own events on the window you set; the identifier is the contact record. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- limit still live? (your credit engine). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- first draws on limits that were sitting idle. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 05Illustrative journey
Bring the Add money visit to a top-up.
A session with the Add money screen opened twice and no top-up sends one push that opens the step they left, and one WhatsApp with the same link if money has not landed by the next day.
- Decides
- a session rule you set.
- Aim
- more first top-ups from users who already tried.
Built in the journey builder
Bring the Add money visit to a top-upFINTECHA session rule, a consent check, one push to the step they left, one WhatsApp if nothing lands.
Campaign StartAdd money twice, no top-up (session rule)
Check Channel ConsentCheck push consent
Push + InboxPush: Add money in two taps
Event CheckTopped up within a day?
Yes
No
End
Message · WhatsAppOne WhatsApp with the same link
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- more first top-ups from users who already tried.
- Trigger
- session rule: Add money twice, no top-up
- Events and identifiers
- session rule: Add money twice, no top-up. Captured by the SDK or web tracker as the session runs, tied to the identified contact. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- None beyond the platform's own records: the contact, its consent, and the delivery record.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- stop · topped up within a day? stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- more first top-ups from users who already tried. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 06Illustrative journey
Catch the wallet that is emptying quietly.
A user whose top-ups have fallen on your RFM windows enters At Risk, gets one Story on the feature they never used and one nudge if they read it; if not, the journey waits and moves them to Lost with no more messages.
- Decides
- your RFM definitions.
- Aim
- the drifting user reached once, before the balance is gone.
Built in the journey builder
Catch the wallet that is emptying quietlyFINTECHOne Story, one nudge if they read it, then silence.
Segment EntryRFM At Risk: top-ups falling (your windows)
StoryStory on the feature they never used
Event CheckRead?
Yes
No
Message · WhatsAppOne nudge on their channel
End
Wait TimeWait 14 days
Segment EntryRFM Lost, no more messages
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- the drifting user reached once, before the balance is gone.
- Trigger
- RFM At Risk: top-ups falling (your windows)
- Events and identifiers
- RFM At Risk: top-ups falling (your windows). Segment membership is recomputed from the contact's own events on the window you set; the identifier is the contact record. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- None beyond the platform's own records: the contact, its consent, and the delivery record.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- RFM Lost, no more messages. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- the drifting user reached once, before the balance is gone. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 07Illustrative journey
Set up autopay on the third bill to the same biller.
A payment event from the receipt you already send, the same biller for a third month, asks your ledger whether the biller is on file, then sends one WhatsApp with Set up autopay or Not now; a tap goes to your system to schedule it.
- Decides
- your ledger and the pattern you define.
- Aim
- bills that pay themselves, and a user who stays.
Built in the journey builder
Set up autopay on the third bill to the same billerFINTECHThe receipt you already send is the trigger; your ledger confirms the biller first.
Campaign StartSame biller paid, third month (receipt event)
API CallBiller on file? Ask your ledger
On file
Not on file
WhatsApp FlowWhatsApp: Set up autopay / Not now
Set up autopay
Not now
No reply
API CallYour system schedules the payment
Message · WhatsAppConfirmation
End
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- bills that pay themselves, and a user who stays.
- Trigger
- same biller paid, third month (receipt event)
- Events and identifiers
- same biller paid, third month (receipt event). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- biller on file? (your ledger) · your system schedules it. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- no tap: silence. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- bills that pay themselves, and a user who stays. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 08Illustrative journey
Finish the KYC that stalled at the document.
A session that started KYC and ended with no document uploaded sends one WhatsApp with a tap to continue where they stopped, checks your ledger, and sends one SMS with the same link if they are still not verified.
- Decides
- a session rule you set; your ledger's KYC status.
- Aim
- more verifications completed.
Built in the journey builder
Finish the KYC that stalled at the documentFINTECHA session rule, a consent check, one WhatsApp, and one SMS if your ledger still says unverified.
Campaign StartKYC started, no document (session rule)
Check Channel ConsentCheck consent
WhatsApp FlowWhatsApp: Continue where you stopped
Tapped
No reply
API CallVerified? Ask your ledger
Verified
Still not verified
Message · SMSOne SMS with the same link
End
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- more verifications completed.
- Trigger
- session rule: KYC started, no document
- Events and identifiers
- session rule: KYC started, no document. Captured by the SDK or web tracker as the session runs, tied to the identified contact. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- verified? (your ledger). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Checked inside the journey at the step shown, and per channel before any send.
- Stops when
- stop when verified. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- more verifications completed. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 09Illustrative journey
Remind on the instalment date, then escalate.
The journey waits until the date your ledger holds, sends Pay now, stops when paid, and escalates by channel if not, with the outcome written back.
- Decides
- your due dates and risk tiers.
- Aim
- higher on-time repayment, lower cost to collect.
Built in the journey builder
Remind on the instalment date, then escalateFINTECHWaits until the date your ledger holds, stops when paid, escalates by channel if not.
Campaign Start · APIInstalment due date (from your ledger)
Wait Until DateWait until the due date
Message · WhatsAppPay now
Event CheckPaid?
Yes
No
End
Message · SMSSMS
IVR CallCall
API CallOutcome to your system
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- higher on-time repayment, lower cost to collect.
- Trigger
- instalment due date (your ledger)
- Events and identifiers
- instalment due date (your ledger). The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- outcome to your system. Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- paid? stop. The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- higher on-time repayment, lower cost to collect. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
PLAYBOOKS · 10Illustrative journey
Grow by referral, credited honestly.
A tap on a per-person link is matched to an install, deterministically on Android and as an estimate on iOS, and the sharer's reward waits for the new user's first payment before your system pays it.
- Decides
- your reward rule; your ledger's first payment.
- Aim
- member-get-member that pays for a paying user, not an install.
Built in the journey builder
Grow by referral, credited honestlyFINTECHThe reward waits for the new user's first payment, not the install.
Campaign StartReferral link tapped (link event)
ConditionInstall matched?
Matched, or estimated on iOS
No install
Event CheckFirst payment by the new user?
Yes
Not yet
API CallReward to the sharer (your system)
Message · WhatsAppConfirmation to the sharer
End
Wait TimeWait 7 days
Push + InboxNudge the new user: first payment
End
End
Drawn as it would run in the builder. Thresholds, windows and channel order are the ones you set; the decision at each API step comes from your system.
- Intended outcome
- member-get-member that pays for a paying user, not an install.
- Trigger
- referral link tapped
- Events and identifiers
- referral link tapped. The trigger arrives from your system by API with your customer identifier and the fields named in the trigger. Example inputs; map them to your own event names and identifiers at setup. Every event carries your customer identifier.
- Your systems in the loop
- yes: reward to the sharer (your system). Your system validates and executes each of these; the journey sends the request and branches on the answer.
- Consent
- Per-channel consent on the contact record is checked before any send.
- Stops when
- The customer completes the step the journey waits for, the deadline on a wait passes, or the branch drawn for silence ends.
- If a channel fails or nobody answers
- A channel that reports failure advances the fallback order on that carrier signal; silence takes the path drawn for it, with the deadline you set. Delivery callbacks that arrive late update the record when they arrive. An API step that answers no, or fails, takes the branch drawn for it; the platform does not act on your system's behalf beyond that request.
- Success metric
- member-get-member that pays for a paying user, not an install. Population: contacts who entered the journey in the window. Compared with the baseline window agreed before the pilot, on the conversion events you define. A before-and-after difference is a comparison, not proof of cause.
What it takes to run
Where a step says your system decides, the journey calls your system and branches on its answer. xNotify carries the journey; it does not become the model.