AI kwa Exception Handling: Malipo ya Simu Yasikwame

Desemba huwa na kitu kimoja cha uhakika Kenya: miamala inaongezeka. Mishahara, biashara za sikukuu, “send for me fare”, na malipo ya bidhaa ndogondogo—kila kitu kinapita kwenye simu. Na ukweli mchungu kwa fintech ni huu: ukikwama kwenye “exceptions” (miamala inayoshindwa au kwenda kinyume na kanuni), wateja hawasubiri. Wanahamia mahali kwingine.

Hapa ndipo mjadala wa exception handling unakuwa wa kimkakati, si wa kiufundi tu. Chanzo chetu cha RSS kilikuwa kinagusia hoja ya msingi: exception handling inahitaji AI, automation, na ISO 20022. Ingawa hatukuweza kufikia makala kamili (ilizuia ufikiaji), hoja yenyewe inaendana moja kwa moja na kile kinachotokea kwenye mfumo wa malipo ya simu Kenya: ujazo mkubwa wa miamala, shinikizo la kufuata kanuni, na hitaji la kurekebisha makosa kwa kasi—bila kuongeza gharama ya timu ya “ops”.

Nitaweka wazi: Most companies get this wrong. Wanatibu exceptions kama “tickets” za kuhamishana kwenye barua pepe na spreadsheets. Wakati ukweli ni kwamba exceptions ni sehemu ya bidhaa yako ya malipo. Zikiharibika, UX yako inaharibika.

Exception handling ni nini kwa fintech ya Kenya (na kwa nini inauma)

Exception handling ni mchakato wa kugundua, kuelewa, na kusuluhisha miamala isiyoenda sawa—kwa usalama, kwa kufuata kanuni, na kwa haraka. Katika mazingira ya malipo ya simu nchini Kenya, exceptions mara nyingi hutokea kwenye maeneo yafuatayo:

• Timeouts na network issues (mteja aliona “failed” lakini fedha ilishuka au ilishikiliwa)
• Mismatch ya taarifa: jina/ID, namba ya simu, au reference haijalingana
• Limits na risk controls: miamala inazuiwa kwa sababu ya kikomo, velocity, au suspicion
• Reversals na chargebacks: madai ya mteja, marejesho, au mgogoro wa muamala
• Integration failures: API errors kati ya wallet, bank rails, na huduma za wafanyabiashara

Hizi si “bugs” tu—ni gharama. Gharama ya moja kwa moja (refunds, penalties, call center), na gharama isiyo ya moja kwa moja (churn, reviews mbaya, kupoteza wafanyabiashara).

Sentensi ya kubeba nyumbani: Kila exception ambayo haijatatuliwa ndani ya dakika chache, inaongeza uwezekano wa mteja kuamini kuwa mfumo wako si wa kuaminika.

Kwa nini AI inafaa zaidi kuliko rules pekee kwenye exceptions

AI inasaidia exception handling kwa kufanya triage ya haraka, kutabiri sababu, na kupendekeza hatua sahihi—kabla binadamu hajaingia. Rules bado zina nafasi (kama “if amount > X then block”), lakini Kenya ina mazingira yanayobadilika: tabia za wateja, mbinu za ulaghai, na mabadiliko ya bidhaa.

AI triage: kupanga vipaumbele vinavyolinda mapato

Badala ya foleni ya “tickets” 2,000 zote zikiwa na uzito sawa, AI inaweza:

1. Kugawa severity: ni nani anahitaji kushughulikiwa sasa hivi (mfanyabiashara mkubwa vs muamala mdogo)
2. Kugundua clusters: exceptions 150 zinazotokana na endpoint moja ya API au node ya partner
3. Kutambua “false failures”: muamala uliokamilika upande mmoja na kushindwa upande mwingine

Matokeo yake: timu ya ops haichoki, na wateja wanaona marekebisho kwa kasi.

Root cause prediction: kupunguza “kutafuta sindano kwenye nyasi”

Kwenye mobile payments Kenya, chanzo cha tatizo mara nyingi ni mchanganyiko wa:

• msongamano wa mfumo
• muda wa majibu wa mshirika
• latency ya telco
• configuration iliyobadilika bila taarifa

Model ya AI (hata ya kiwango cha kati) inaweza kujifunza “signature” za makosa—mfano, timeout + route fulani + time window—na kutoa utabiri wa chanzo cha tatizo na hatua.

AI kwa mawasiliano ya wateja (sehemu ya series yetu)

Ndani ya mfululizo wetu wa “Jinsi Akili Bandia Inavyoendesha Sekta ya Fintech na Malipo ya Simu Nchini Kenya”, pointi kubwa ni hii: AI si ya risk pekee. Ni ya communication pia.

Kwa exception, AI inaweza:

• Kuandika ujumbe wa SMS/WhatsApp/app notification unaoeleweka (“Fedha yako haijapotea; tumeishikilia na tunaikamilisha ndani ya dakika 3…”)
• Kutoa ETA ya suluhisho kwa kuzingatia historia ya matukio
• Kuongoza agent wa call center kwa “next best action”

Wateja wakielewa kinachoendelea, hasira inapungua. Hii ni retention, si “support”.

Automation: tofauti kati ya “kusuluhisha” na “kusuluhisha kwa kiwango”

Automation inafanya exception handling iwe ya kiwango (scalable) kwa kuchukua hatua bila kusubiri binadamu. Kenya ina volumes kubwa; ukitegemea manual intervention, utaongeza watu badala ya kuongeza faida.

Uendeshaji wa “straight-through exception resolution”

Sehemu ya exceptions zinaweza kusuluhishwa bila binadamu, kwa kutumia flows zilizoidhinishwa:

• Auto-retry kwa miamala yenye transient errors (kwa mipaka ya retries)
• Auto-reconcile kwa kulinganisha ledger, wallet, na confirmations
• Auto-reverse kwa kesi zenye ushahidi wa kutosha (mfano, double debit)
• Auto-hold & release kwa miamala inayohitaji uhakiki wa ziada

Kanuni yangu: kama una uwezo wa kuelezea hatua ya suluhisho kwa flowchart, una uwezo wa ku-automate.

Exception playbooks: kufanya ops iwe bidhaa

Badala ya “knowledge” kukaa kichwani kwa watu wawili, tengeneza playbooks:

• Trigger (ishara ya tatizo)
• Data ya kukusanya (logs, references, partner responses)
• Hatua za kuchukua (retry/reverse/hold)
• Ujumbe wa mteja (kwa lugha rahisi)
• SLA na escalation

AI inafanya playbooks ziwe “smart” kwa kupendekeza playbook sahihi kulingana na pattern.

ISO 20022: kwa nini standard hii inaingia kwenye mazungumzo ya Kenya

ISO 20022 ni kiwango cha ujumbe wa malipo kinacholenga data iliyo wazi, structured, na yenye maana zaidi. Kwa exception handling, hii ni faida kubwa kwa sababu exceptions nyingi hutokea kwa “missing or messy data”.

Data tajiri = uchunguzi wa haraka

Ujumbe ulio na fields zilizo wazi (party identifiers, purpose codes, structured remittance info) unarahisisha:

• kuoanisha muamala na ankara/reference
• kupunguza makosa ya “name mismatch” au “reference missing”
• kufanya compliance screening iwe sahihi zaidi (badala ya “fuzzy matching” ovyo)

Kwa fintech zinazounganisha mobile money ↔ benki ↔ wafanyabiashara ↔ cross-border rails, standardization ndiyo glue. Bila hiyo, exceptions zinaongezeka kadri integrations zinavyoongezeka.

Compliance na audit trail

Kenya ina msukumo unaoendelea wa kuboresha ufuatiliaji wa miamala, AML, na consumer protection. ISO 20022 inasaidia kwa:

• kuweka data ya muamala kwenye muundo unaoeleweka
• kurahisisha audit trail
• kupunguza “manual investigations” zisizoisha

Ninapenda kusema hivi: ukijenga exception handling bila kufikiria data standards, unaweka deni la kiufundi kwenye risk na ops.

Muundo unaofanya kazi: jinsi ya kujenga AI + automation kwa exceptions

Muundo bora una nguzo 4: observability, decisioning, orchestration, na communication. Hii ndiyo blueprint inayofaa kwa fintech na mobile payment platforms Kenya.

1) Observability: uone tatizo kabla halijalalamikiwa

• Centralized logs + tracing kwa miamala
• Dashboards za partner latencies, failure rates, reversal queues
• Alerts zinazoangalia rate of change (spikes), si “threshold” tu

Kigezo cha ubora: unajua tatizo kabla call center haijapigiwa mara 50.

2) Decisioning: rules + AI kwa pamoja

• Rules kwa compliance “must-haves”
• AI kwa pattern detection, priority scoring, root cause prediction
• Human-in-the-loop kwa kesi za juu (high value, high risk)

Kigezo cha ubora: model inaelezeka (explainable) kwa ops na risk, si “black box”.

3) Orchestration: automation iliyo na guardrails

• Workflows zenye idhini: retry, reverse, hold, request-more-info
• Rate limits na approval gates kwa miamala mikubwa
• Full audit logs za hatua zote

Kigezo cha ubora: unapunguza muda wa wastani wa suluhisho (MTTR) bila kuongeza fraud exposure.

4) Communication: uaminifu kwa mteja

• Status updates zinazoeleweka
• Self-serve “track my transaction” ndani ya app/USSD
• Templates za lugha rahisi (Kiswahili/English/Sheng kulingana na brand)

Kigezo cha ubora: malalamiko yanapungua hata kabla exceptions hazijashuka.

Maswali ambayo timu nyingi huuliza (na majibu ya moja kwa moja)

Je, AI itachukua nafasi ya ops team?

Hapana. AI itapunguza kazi ya kurudia-rudia na kuacha timu ishughulikie kesi ngumu: disputes, fraud rings, partner escalations, na policy decisions.

Ni data gani ya kuanza nayo?

Anza na vitu vinavyokaa tayari:

• transaction IDs, timestamps, amounts
• error codes/messages kutoka APIs
• partner response times
• reversal outcomes
• customer complaints categories

Ukikusanya kwa usafi kwa miezi 2–3, tayari unaweza kujenga triage model ya msingi.

ISO 20022 ni lazima leo?

Si lazima kwa kila rail mara moja, lakini ni mwelekeo sahihi. Kama unapanua kwenda benki nyingi, cross-border, au corporate payments, kuandaa data yako kwa ISO 20022 mapema kunapunguza exceptions baadaye.

Hatua za haraka (wiki 4) kwa fintech ya Kenya inayotaka matokeo

Huu ni mpango wa vitendo ambao nimeona ukifanya kazi, bila kuanza “big bang” project:

1. Chagua exception 3 zinazoleta maumivu zaidi (kwa volume au kwa gharama)
2. Pima baseline: failure rate, MTTR, idadi ya tickets, na churn/complaints
3. Tengeneza playbook moja kwa kila exception (trigger → action → message)
4. Automate hatua moja salama (mfano, auto-retry yenye limit)
5. Ongeza AI triage (priority scoring + clustering) kabla ya AI “kubwa”
6. Boresha mawasiliano: status updates + ETA + lugha rahisi

Ukifanya haya, unapata ushindi wa mapema unaoleta uaminifu wa ndani na bajeti ya kuendelea.

Unachopata ukifanya vizuri: malipo yasikwame, compliance ipunguze mzigo

Exception handling yenye AI + automation + mwelekeo wa ISO 20022 ina matokeo matatu yanayoonekana:

• Wateja wanapata uzoefu thabiti (malipo ya simu hayakwami bila maelezo)
• Ops inakuwa nyepesi (kazi nyingi zinaenda straight-through)
• Compliance inakuwa rahisi (data iko structured, audit trail iko wazi)

Kwa mfululizo wetu wa Jinsi Akili Bandia Inavyoendesha Sekta ya Fintech na Malipo ya Simu Nchini Kenya, huu ni ujumbe mkuu: AI si pambo. Ni miundombinu ya uaminifu.

Ukiangalia 2026 inavyokuja—volumes kuongezeka, integrations kuongezeka, na matarajio ya wateja kupanda—swali la vitendo ni hili: exceptions zako zitaendelea kuwa “kazi ya kuzima moto”, au zitakuwa mfumo unaojirekebisha unaolinda mapato na uaminifu?