Kuunganisha mfumo mkuu wa benki na goAML: chaguo za API, SFTP na CSV

Kila jukwaa la kuripoti la AML (kupambana na utakatishaji fedha haramu) kupitia goAML ni zuri kwa kiwango kilekile cha ubora wa data inayoingizwa ndani yake. Injini ya kisasa zaidi ya kutengeneza XML, modeli ya ukadiriaji wa hatari iliyorekebishwa kwa uangalifu mkubwa zaidi, na mtiririko wa kazi wa uzingatiaji uliobuniwa vizuri zaidi — vyote hudhoofishwa ikiwa data ya miamala iliyo chini yake haijakamilika, iko katika muundo usio sahihi, au imeingizwa upya kwa mkono kutoka kwenye ripoti ya mfumo mkuu wa benki (core banking) na mchambuzi wa uzingatiaji aliyesoma vibaya sehemu ya tarehe.

Muunganisho kati ya mfumo mkuu wa benki na jukwaa la benki hiyo la kuripoti AML ndio uamuzi wa kiufundi wenye athari kubwa zaidi katika utekelezaji mzima. Ukiufanya ipasavyo, kitengo cha uzingatiaji kinafanya kazi kwa data ya miamala iliyo sahihi, kamili na inayopatikana kwa wakati, huku uingiliaji kati wa mkono ukiwa mdogo kabisa. Ukiukosea, timu ya uzingatiaji hutumia muda mwingi kuthibitisha ubora wa data sawa na inavyoutumia kwenye uchambuzi halisi wa uzingatiaji.

Habari njema ni kwamba njia tatu za muunganisho zinazopatikana — REST API, uhamishaji wa faili kwa SFTP, na kuingiza data kwa CSV/Excel — zinashughulikia wigo mzima wa uwezo wa kiufundi wa taasisi za fedha za Afrika Mashariki, kuanzia benki zilizozaliwa kidijitali zenye mifumo mikuu ya benki iliyojengwa kwa ajili ya wingu, hadi taasisi za kijamii zenye mifumo ya zamani na miundombinu midogo ya TEHAMA.

---

Kwa nini muunganisho ni muhimu kwa uzingatiaji wa goAML

GIGO: data mbovu ikiingia, XML mbovu hutoka

Skima ya XSD ya goAML ni kali. Kila hati ya XML inayowasilishwa huthibitishwa dhidi ya skima na dhidi ya kanuni za kibiashara mahususi kwa kila nchi. Kiasi kilichohifadhiwa katika mfumo mkuu wa benki kama maandishi yenye kitenganishi cha maelfu ("1,250,000") lazima kibadilishwe kuwa desimali yenye tarakimu mbili kamili baada ya nukta ("1250000.00"). Tarehe iliyohifadhiwa katika muundo wa DD/MM/YYYY lazima iwe YYYY-MM-DD. Aina ya muamala iliyohifadhiwa kama msimbo wa tarakimu ("01" kwa amana ya fedha taslimu) lazima ioanishwe na thamani ya enumeration ya goAML ("CASH_DEPOSIT").

Ikiwa mabadiliko haya hayafanyiki kiotomatiki katika tabaka la muunganisho lililobuniwa vizuri, lazima yafanyike kwa mkono — na uandaaji wa data kwa mkono ndio chanzo cha makosa mengi ya uwasilishaji wa goAML. Hata maafisa uzingatiaji wenye ujuzi mkubwa hufanya makosa ya unakili wanapobadilisha data kutoka muundo mmoja hadi mwingine kwa mkono chini ya shinikizo la muda.

Tabaka imara la muunganisho hufanya mabadiliko yote kiotomatiki na kwa utaratibu. Hulazimisha ubora wa data pale inapoingizwa, kabla data haijaingia katika mtiririko wa kazi wa uzingatiaji, huku timu ya uzingatiaji ikielekeza umakini wake kwenye uchambuzi badala ya kusafisha data.

Kuingiza data upya kwa mkono ndicho chanzo cha makosa mengi ya goAML

Katika benki zisizo na muunganisho wa kiotomatiki na mfumo mkuu wa benki, mtiririko wa kazi wa kawaida ni huu: timu ya TEHAMA huendesha ripoti ya miamala kutoka kwenye mfumo mkuu wa benki na kuiwasilisha kama faili ya Excel; mchambuzi wa uzingatiaji huhamisha data husika, huoanisha kwa mkono sehemu na muundo wa XML ya goAML, hujaza kiolezo cha goAML, kisha huwasilisha. Kila hatua ya mkono hufungua mianya ya makosa.

Makosa yanayojitokeza zaidi kutokana na kuingiza data upya kwa mkono ni pamoja na: kugeuzwa kwa muundo wa tarehe (6 Machi kuingizwa kama 3 Juni), makosa ya mahali pa nukta ya desimali (KES 125,000 kuingizwa kama KES 12,500 au KES 1,250,000), kukatika kwa sehemu ya jina, tarakimu za namba ya akaunti kubadilishana nafasi, na misimbo ya sarafu isiyolingana. Kosa lolote kati ya haya husababisha XML iliyowasilishwa kushindwa ama uthibitishaji wa skima ama uthibitishaji wa kanuni za kibiashara katika lango la FIU (kitengo cha taarifa za kifedha).

Muunganisho huondoa hatua ya unakili unaofanywa na binadamu

Muunganisho wa moja kwa moja kati ya mfumo mkuu wa benki na jukwaa la AML unamaanisha kwamba data ya miamala hutiririka kielektroniki, huku kanuni zilizofafanuliwa za kubadilisha data zikitumika kiprogramu na kwa uthabiti. Mchambuzi wa uzingatiaji hagusi kamwe data ghafi za miamala — hufanya kazi na data za kesi zilizokwisha kuthibitishwa na kupangwa katika muundo sahihi, kupitia kiolesura chenye muundo maalum. Muda wake hutumika katika uchambuzi na kufanya maamuzi ya kitaalamu, si katika kuandaa data.

---

Njia ya 1 ya muunganisho: REST API

Jinsi inavyofanya kazi

Muunganisho wa REST API huliwezesha jukwaa la AML kuomba data ya miamala kutoka kwenye tabaka la API la mfumo mkuu wa benki kwa ratiba iliyopangwa au kutokana na tukio fulani. Jukwaa la AML hujithibitisha kwa API ya mfumo mkuu wa benki, huomba miamala inayolingana na vigezo mahususi (kipindi cha tarehe, aina ya muamala, kiwango cha kiasi), hupokea jibu katika muundo wa JSON au XML, na huoanisha sehemu za jibu na muundo wa ndani wa data wa jukwaa la AML.

Njia hii inawezesha upatikanaji wa data papo hapo na karibu papo hapo. Kwa kutoa tahadhari za taarifa ya miamala yenye mashaka (STR) — pale mwenendo wa muamala wenye mashaka unapohitaji kufikishwa kwa afisa uzingatiaji haraka iwezekanavyo baada ya kutokea — kuuliza API karibu papo hapo kila baada ya dakika 15 hadi 60 hutoa data ya kisasa zaidi.

Kwa ufuatiliaji wa kiwango cha taarifa ya miamala ya fedha taslimu (CTR), kuingiza data kupitia API huwezesha kugundua karibu papo hapo kila muamala unaofikia kiwango kinacholingana na USD 15,000, ili miamala inayostahili iweze kuonyeshwa na kesi za CTR kufunguliwa ndani ya muda wa mwisho wa kuwasilisha, yaani Ijumaa ya wiki husika.

Mifumo mikuu ya benki yenye REST API katika Afrika Mashariki

Temenos T24 R20+ ina kijenzi cha T24 API Server, ambacho hufichua hoja (enquiries) zinazotegemea TAFJ kama ncha (endpoints) za RESTful. Kupata data ya miamala kunahitaji ufafanuzi wa enquiry katika T24 unaobainisha sehemu na vigezo vya kuchuja, unaofichuliwa kupitia API Server. T24 API Server inawezesha uthibitishaji wa utambulisho kwa OAuth 2.0 client credentials.

Infosys Finacle 10 na 11 zina Finacle Connect API Gateway, inayotoa ncha za REST kwa data za akaunti, wateja na miamala. Mfumo wa API wa Finacle unawezesha hoja za papo kwa papo (synchronous) na pia arifa za webhook zisizo za papo kwa papo (asynchronous) kuhusu matukio ya miamala.

Oracle FlexCube (FCUBS 12+) hutoa tabaka la huduma za RESTful kupitia Service Framework yake. Huduma za REST za FlexCube zinahitaji usanidi unaofaa wa uratibu wa huduma (service orchestration) na zinawezesha uthibitishaji wa utambulisho kwa OAuth 2.0 bearer token.

Mambu kwa asili yake imejengwa kwa kuanzia na API (API-first). Mambu Core Banking Platform hufichua REST API pana bila kuhitaji usanidi wa ziada. Data ya miamala inapatikana kupitia ncha za Loans, Savings na Current Account, zikiwa na uwezo mpana wa kuchuja na kugawa matokeo katika kurasa (pagination).

Uthibitishaji wa utambulisho

Muunganisho wa API hujithibitisha kwa kutumia ama mtiririko wa OAuth 2.0 client credentials (unaopendekezwa kwa muunganisho wa seva kwa seva) ama uthibitishaji kwa ufunguo wa API (API key). Jukwaa la AML huhifadhi vitambulisho vya kuingia (credentials) katika hifadhi ya siri iliyosimbwa fiche na huviwasilisha katika kila ombi. Mawasiliano yote ya API hufanyika kupitia HTTPS/TLS 1.2 au toleo la juu zaidi.

Matumizi yanayopendekezwa

Muunganisho wa REST API ndiyo njia inayopendelewa kwa:

• Kutoa tahadhari za STR papo hapo au karibu papo hapo kutokana na ufuatiliaji wa miamala
• Kugundua kwa kila muamala kiwango cha CTR kinacholingana na USD 15,000, pamoja na ubadilishaji wa sarafu papo hapo
• Kuongeza taarifa za Mjue Mteja Wako (KYC) za mteja (tarehe ya kufungua akaunti, kazi iliyotangazwa, daraja la hatari)
• Data ya miamala ya fedha za simu kutoka Daraja API au Airtel Money API

Maelezo ya usanifu wa muunganisho

Huduma ya kuingiza data ya jukwaa la AML huendesha kazi iliyopangwa kwa ratiba inayouliza API ya mfumo mkuu wa benki katika vipindi vinavyoweza kusanidiwa. Huduma hiyo hujithibitisha, huomba miamala tangu muhuri wa muda wa uulizaji wa mwisho uliofanikiwa, huoanisha sehemu za jibu na muundo wa ndani wa miamala (ikisawazisha tarehe, ikipanga muundo wa kiasi, ikitafsiri misimbo na ikioanisha wahusika), na huandika rekodi zilizosawazishwa kwenye hifadhi ya miamala. Miito ya API iliyoshindwa hujaribiwa tena kwa muda wa kusubiri unaoongezeka kwa kasi (exponential backoff) na huandikwa kwenye kumbukumbu pamoja na muktadha kamili wa kosa ili timu ya uendeshaji iweze kuiona.

---

Njia ya 2 ya muunganisho: uhamishaji wa faili kwa SFTP

Jinsi inavyofanya kazi

Muunganisho wa SFTP hutumia uhamishaji wa faili uliopangwa kwa ratiba kutoka kwenye mfumo mkuu wa benki kwenda kwenye seva ya SFTP inayoshirikiwa. Uchakataji wa makundi (batch) wa mfumo mkuu wa benki (kwa kawaida husanidiwa kama sehemu ya uchakataji wa mwisho wa siku) hutengeneza faili ya data ya miamala iliyochopolewa (extract) katika muundo uliofafanuliwa — CSV, iliyotenganishwa kwa alama ya pipe, au yenye upana maalum (fixed-width) — na kuiweka kwenye saraka ya SFTP iliyoteuliwa. Huduma ya kuingiza data ya jukwaa la AML hufuatilia saraka ya SFTP, hugundua faili mpya, huzipakua na kuzichakata, na huzihamishia kwenye saraka ya kumbukumbu (archive) baada ya kuzichakata kwa mafanikio.

Huu ni mtindo uliozoeleka na unaoungwa mkono na mifumo mingi, usiohitaji mabadiliko yoyote katika mfumo mkuu wa benki zaidi ya kusanidi ripoti ya uchopoaji na kazi ya SFTP. Mifumo mingi mikuu ya benki iliyosimikwa Afrika Mashariki ina uwezo wa kuhamisha data kwa SFTP katika usakinishaji wake wa kawaida.

Miundo ya faili inayotumika

CSV (thamani zilizotenganishwa kwa koma) ndio muundo unaotumika zaidi kwa data iliyochopolewa kutoka T24 na Finacle. Vichwa vya safu katika mstari wa kwanza hufafanua uoanishaji wa sehemu. Usanidi wa kuingiza data wa jukwaa la AML huoanisha majina ya safu za CSV na sehemu za muundo wa ndani wa data na hutumia kanuni za kubadilisha data.

Faili zilizotenganishwa kwa alama ya pipe ni za kawaida katika data inayohamishwa na T24 COB (Close of Business), hasa katika usakinishaji wa zamani wa T24. Kutumia alama ya pipe (|) kama kitenganishi huepusha utata na koma zinazoweza kuonekana katika sehemu za maandishi kama vile maelezo ya miamala.

Faili zenye upana maalum (fixed-width) hupatikana katika usakinishaji wa zamani wa FlexCube ambapo kila sehemu huchukua idadi iliyofafanuliwa ya nafasi za herufi. Kuchakata faili zenye upana maalum kunahitaji maelezo ya mpangilio wa sehemu (nafasi zipi za herufi zinalingana na sehemu ipi) yaliyoandikwa katika usanidi wa uchopoaji wa mfumo mkuu wa benki.

Ratiba na muda

Kwa asili yake, muunganisho wa SFTP unategemea makundi (batch). Ratiba ya kawaida ni uchopoaji wa mwisho wa siku unaojumuisha miamala yote tangu uchopoaji uliotangulia. Kwa ufuatiliaji wa kiwango cha CTR, uchakataji wa makundi wa mwisho wa siku unawezekana lakini unabana muda: muda wa mwisho wa kuwasilisha wa Ijumaa ya wiki husika unamaanisha kwamba muamala wa Jumatatu lazima ugunduliwe, upitiwe, uidhinishwe na uwasilishwe ndani ya siku nne za kazi, na muamala wa Alhamisi ndani ya siku moja. SFTP ya mwisho wa siku inakubalika kwa taasisi zenye mitiririko ya kazi ya uzingatiaji iliyokomaa, lakini uchopoaji mara kadhaa ndani ya siku — au kuhamia kuingiza data kupitia API — hupunguza kwa kiasi kikubwa hatari ya kukosa muda wa mwisho.

Kwa taasisi zinazohitaji kugundua viwango vya kuripoti ndani ya siku (ili kutambua miamala ya fedha taslimu inayofikia au kuzidi kiasi kinacholingana na USD 15,000 mara tu inaporekodiwa), uchopoaji wa ziada ndani ya siku unaweza kusanidiwa, kwa kawaida adhuhuri. Baadhi ya mifumo mikuu ya benki inawezesha uchopoaji unaoanzishwa kiotomatiki katika vipindi vinavyoweza kusanidiwa ndani ya siku.

Njia inayotumika zaidi kwa T24 na Finacle

Uchopoaji kwa SFTP ndiyo, kwa mbali, njia ya muunganisho inayotumika zaidi katika sekta ya benki ya Afrika Mashariki. Faida zake ni urahisi, kutumika kila mahali (mifumo yote mikuu ya benki inaiwezesha), kutotegemea kabisa upatikanaji wa tabaka la API la mfumo mkuu wa benki, na zana zilizokomaa zinazopatikana kwa ufuatiliaji na uchakataji wa SFTP.

Taasisi zisizo na uwezo wa haraka wa kupata wataalamu wa kusanidi T24 API Server, au ambazo leseni ya Finacle Connect Gateway yao bado haijapatikana, zinaweza kutekeleza muunganisho wa SFTP kwa usanidi wa kawaida wa ripoti na vitambulisho vya kuingia vya SFTP — kazi zinazoweza kufanywa na timu nyingi za uendeshaji wa TEHAMA bila kuhitaji wataalamu maalum wa uundaji wa programu.

Usalama: itifaki ya SFTP, uthibitishaji kwa funguo, faili zilizosimbwa fiche

SFTP (SSH File Transfer Protocol) hutoa usimbaji fiche imara katika tabaka la usafirishaji, tofauti na FTP ya zamani inayosafirisha data kama maandishi wazi (cleartext). Uthibitishaji wa utambulisho kwa funguo za SSH huondoa hatari za kiusalama zinazohusiana na nywila. Faili za data ya miamala iliyochopolewa zenye taarifa za wateja zinapaswa pia kusimbwa fiche zikiwa zimehifadhiwa (at rest) kwa kutumia PGP au AES-256 kabla ya kuwekwa kwenye seva ya SFTP, na kufunguliwa na jukwaa la AML baada ya kupakuliwa. Usalama huu wa tabaka nyingi huhakikisha kwamba hata vitambulisho vya kuingia vya SFTP vikivuja, faili za data ya miamala haziwezi kusomeka bila ufunguo wa kufungua usimbaji fiche.

---

Njia ya 3 ya muunganisho: kuingiza CSV/Excel

Matumizi

Kuingiza CSV/Excel kwa mkono kunatolewa kama njia mbadala ya muunganisho kwa taasisi zisizo na miundombinu au rasilimali za TEHAMA kwa ajili ya muunganisho wa kiotomatiki kupitia API au SFTP. Hili linahusu hasa SACCO ndogo (vyama vya ushirika wa akiba na mikopo), taasisi za fedha ndogo (microfinance) za daraja la 3, na benki za kijamii ambazo huenda hazina wafanyakazi maalum wa uendeshaji wa TEHAMA.

Afisa uzingatiaji (au mfanyakazi wa TEHAMA aliyeteuliwa) huhamisha ripoti ya miamala kutoka kwenye mfumo mkuu wa benki, huipakua katika muundo wa CSV au Excel, na kuipakia kwenye jukwaa la AML kupitia kiolesura cha kuingiza data. Jukwaa huthibitisha muundo wa faili, huoanisha safu na muundo wa data, huwekea alama matatizo ya ubora wa data ili yapitiwe, na huingiza miamala katika mtiririko wa kazi wa uzingatiaji.

Muundo wa kiolezo cha kawaida

Jukwaa la AML hutoa kiolezo cha kuingiza data katika muundo wa Excel kinachoweza kupakuliwa, ambacho hufafanua mapema muundo wa safu unaohitajika, miundo ya data inayokubalika kwa kila sehemu, na kanuni za uthibitishaji. Taasisi zinazotumia faili maalum za CSV zinazohamishwa kutoka kwenye mfumo wao mkuu wa benki hutumia usanidi wa kuoanisha safu ili kufafanua ni safu ipi katika faili yao inayolingana na sehemu ipi katika kiolezo. Uoanishaji huu husanidiwa mara moja na kuhifadhiwa, hivyo uingizaji unaofuata unahitaji hatua ya kupakia faili pekee.

Uthibitishaji wa data wakati wa kuingiza

Mtiririko wa kuingiza data hutumia uthibitishaji uleule wa ubora wa data unaotumiwa na mitiririko ya kiotomatiki ya kuingiza data:

• Uthibitishaji na usawazishaji wa muundo wa tarehe
• Uthibitishaji wa muundo wa kiasi (tarakimu, nafasi mbili za desimali)
• Kugundua miamala iliyojirudia (miamala ambayo tayari iko kwenye mfumo huwekewa alama na kurukwa)
• Ukaguzi wa kuwepo kwa sehemu za lazima
• Uthibitishaji wa muundo wa namba ya akaunti
• Ukaguzi wa sehemu za utambulisho wa mteja

Makosa ya uthibitishaji huonyeshwa katika ripoti ya muhtasari ambayo mtumiaji anayeendesha uingizaji huipitia kabla ya kuthibitisha uingizaji. Rekodi zenye makosa yasiyo makubwa zinaweza kuingizwa zikiwa na alama za kupitiwa kwa mkono; rekodi zenye makosa makubwa huondolewa na lazima zisahihishwe katika data chanzo na kupakiwa upya.

Mapungufu

Kuingiza CSV/Excel kwa mkono kuna mapungufu mawili makubwa ukilinganisha na muunganisho wa kiotomatiki:

Kwanza, kunaanzishwa kwa mkono. Afisa uzingatiaji lazima akumbuke kufanya uingizaji kwa ratiba sahihi. Uingizaji unaorukwa unamaanisha mapengo katika data ya miamala inayolisha ufuatiliaji wa viwango vya kuripoti na ukadiriaji wa hatari, jambo linaloweza kusababisha CTR kutowasilishwa.

Pili, kumbukumbu za ukaguzi kuhusu asili ya data hazijakamilika kwa kiwango sawa. Miunganisho ya kiotomatiki hurekodi mfumo chanzo halisi, muhuri wa muda wa uhamishaji, na njia ya usafirishaji kwa kila rekodi iliyoingizwa. Uingizaji wa mkono hurekodi tu jina la faili, muhuri wa muda wa kupakia, na mtumiaji aliyepakia — taarifa ambazo huenda hazitoshi kufuatilia asili ya data katika uchunguzi.

Kwa sababu hizi, kuingiza CSV/Excel kunapaswa kuchukuliwa kama njia ya mpito wakati muunganisho wa kiotomatiki ukitekelezwa, si kama usanifu wa kudumu wa muunganisho kwa taasisi zenye wajibu mkubwa wa kuripoti.

---

Muunganisho wa data ya fedha za simu

M-PESA Daraja API

Daraja API ya M-PESA (jukwaa la API la Safaricom kwa wasanidi programu) hutoa ufikiaji wa data ya miamala ya M-PESA kwa biashara zilizosajiliwa. Kwa benki zenye miunganisho ya M-PESA Pay Bill au Buy Goods, Daraja C2B (Customer to Business) API hutuma arifa za miamala papo hapo kama callback za HTTP mteja anapofanya malipo.

Kwa madhumuni ya ufuatiliaji wa viwango vya AML, ncha husika za Daraja ni:

• C2B API: Hupokea arifa za papo hapo za malipo ya M-PESA kwenda kwenye namba ya Pay Bill ya benki
• Account Balance API: Huuliza salio la sasa la akaunti kwa short code mahususi ya Pay Bill
• Transaction Status API: Huuliza hali ya muamala mahususi wa M-PESA kwa kitambulisho chake cha kipekee cha muamala

Daraja API hutumia uthibitishaji wa utambulisho wa OAuth 2.0 kwa consumer key/secret. Jukwaa la AML hujisajili kama C2B callback URL ili kupokea arifa za malipo papo hapo, husawazisha data ya miamala ya M-PESA (MSISDN, kiasi, kitambulisho cha muamala, muhuri wa muda, rejea ya akaunti) kulingana na muundo wa ndani wa miamala, na huijumuisha katika mtiririko uleule wa ufuatiliaji wa viwango vya kuripoti unaotumika kwa miamala ya matawi na ya ATM.

Airtel Money API

API ya Airtel Money hutoa utendaji unaofanana na M-PESA Daraja kwa benki zenye miunganisho ya wafanyabiashara wa Airtel Money. Muundo wa uthibitishaji wa utambulisho na mtindo wa callback vinalingana, ingawa kuna kaida za kutaja sehemu zilizo mahususi kwa Airtel zinazohitaji kuoanishwa na muundo wa data uliosawazishwa wa jukwaa la AML.

T-Kash (Telkom Kenya)

T-Kash hutoa ufikiaji wa API kwa wasanidi programu kwa ajili ya miunganisho ya kibiashara, ingawa sehemu yake ya soko ni ndogo sana kuliko ya M-PESA. Benki zenye akaunti za wafanyabiashara za T-Kash zinaweza kuunganisha data ya miamala ya T-Kash kupitia tabaka lake la API la biashara.

Ufuatiliaji katika njia zote za miamala kwa ajili ya kugundua CTR na STR

Sharti muhimu zaidi la muunganisho wa fedha za simu ni kwamba miamala ya M-PESA itathminiwe katika mtiririko uleule wa ugunduzi unaotumika kwa miamala ya fedha taslimu ya matawi, utoaji wa fedha kwenye ATM, na kila njia nyingine inayohamisha fedha za wateja. Miamala ya fedha taslimu ya matawi na ya ATM hupimwa mmoja mmoja dhidi ya kiwango cha CTR kinacholingana na USD 15,000; kwa fedha za simu, tumia utaratibu ambao umeuthibitisha na FRC (Financial Reporting Centre ya Kenya), kwa sababu hakuna kati ya POCAMLA, Kanuni za 2023 wala Waraka wa FRC Na. 4 wa 2023 kinachoshughulikia suala hilo. Sambamba na hilo, shughuli zilizo chini ya kiwango katika njia zote hulisha uangalizi wa mienendo ya ugawanyaji wa miamala (structuring) unaozaa kesi za STR. Njia zote mbili zinahitaji tabaka moja la utambulisho wa mteja linalounganisha MSISDN ya M-PESA ya mteja na kitambulisho chake cha mteja na namba ya akaunti katika mfumo mkuu wa benki.

Kuoanisha utambulisho ndicho kipengele chenye changamoto kubwa kiufundi: akaunti ya M-PESA ya mteja hutambulishwa kwa namba yake ya simu ya mkononi, ilhali akaunti yake katika mfumo mkuu wa benki hutambulishwa kwa namba ya akaunti na kitambulisho cha mteja. Jukwaa la AML hutunza jedwali la marejeo mtambuka la wateja linalooanisha MSISDN na vitambulisho vya wateja, likijazwa kutoka kwenye kumbukumbu za KYC za benki. Marejeo haya mtambuka huwezesha kumtambua mteja kwa uthabiti katika njia zote za miamala.

---

Uoanishaji wa data — sehemu za mfumo mkuu wa benki na skima ya goAML

Jedwali lifuatalo linaonyesha uoanishaji wa sehemu kutoka kwenye data ya kawaida ya miamala inayochopolewa kutoka Temenos T24 hadi elementi za XML ya goAML, pamoja na ubadilishaji unaohitajika kwa kila sehemu.

---

Hakuna mabadiliko yanayohitajika katika mfumo wako mkuu wa benki

Wasiwasi mmoja unaojitokeza mara kwa mara katika majadiliano kuhusu muunganisho wa AML ni suala la kubadilisha mfumo mkuu wa benki. Benki zina haki ya kuwa waangalifu kuhusu mabadiliko yoyote katika mfumo wao mkuu — ndio mfumo muhimu zaidi katika taasisi, mabadiliko yanahitaji majaribio ya kina, na huenda idhini ya muuzaji ikahitajika.

Muunganisho wa jukwaa la AML umebuniwa kuwa wa kusoma tu kikamilifu. Jukwaa la AML huuliza data ya miamala lakini kamwe haliandiki chochote kurudi kwenye mfumo mkuu wa benki. Hakuna stored procedures, triggers wala mabadiliko ya skima yanayohitajika katika hifadhidata ya mfumo mkuu wa benki. Hakuna programu wakala (agents) wala michakato ya nyuma inayosakinishwa kwenye seva za mfumo mkuu wa benki. Muunganisho ni mtiririko wa data wa upande mmoja: kutoka mfumo mkuu wa benki kwenda jukwaa la AML.

Kwa muunganisho unaotegemea API, API Server ya mfumo mkuu wa benki ni kijenzi kilichotengana na programu ya mfumo mkuu wa benki yenyewe — kuita API hakubadilishi wala hakuhatarishi programu ya mfumo mkuu wa benki. Kwa muunganisho unaotegemea SFTP, mfumo mkuu wa benki hutengeneza faili ya ripoti kama sehemu ya uchakataji wake wa makundi uliopo — huu ni uwezo wa kawaida wa kutoa ripoti unaoongeza mzigo mdogo mno.

Mbinu isiyomtegemea muuzaji yeyote

Tabaka la kuingiza data la jukwaa la AML limebuniwa kukubali muundo mahususi wa data na mpangilio wa mfumo wowote mkuu wa benki bila kuhitaji ushiriki wa muuzaji wa mfumo huo. Muunganisho husanidiwa na timu ya TEHAMA ya benki kwa kutumia ufafanuzi wa uoanishaji wa sehemu na kanuni za kubadilisha data zinazotunzwa katika usanidi wa jukwaa la AML — si katika mfumo mkuu wa benki.

Mbinu hii isiyomtegemea muuzaji yeyote inamaanisha kwamba benki ikibadilisha mfumo mkuu wa benki, usanidi wa muunganisho husasishwa katika jukwaa la AML, badala ya kujengwa upya kuanzia mwanzo. Kitengo cha uzingatiaji huendelea kufanya kazi wakati wa kuhamia mfumo mkuu mpya wa benki.

Ratiba ya utekelezaji

Kwa kawaida muunganisho na mfumo mkuu wa benki hukamilika ndani ya wiki 1 hadi 2 kama sehemu ya utekelezaji wa kawaida wa jukwaa la AML wa wiki 6 hadi 8. Hatua ya kusanidi muunganisho inahitaji ushiriki wa timu ya TEHAMA ya benki inayohusika na mfumo mkuu wa benki (ili kuthibitisha majina ya sehemu, miundo, na mipango ya ufikiaji wa SFTP au API) na kwa kawaida hukamilika ndani ya siku chache tangu mradi kuanza. Muda uliobaki wa utekelezaji hutumika kwa majaribio, uthibitishaji wa ubora wa data, mafunzo kwa timu ya uzingatiaji, na usanidi wa lango la FIU.

---

Chukua hatua inayofuata

Jukwaa la Ripoti za goAML la Creodata lina tabaka nyumbufu la kuingiza data linalowezesha REST API, SFTP na kuingiza CSV/Excel kwa mifumo yote mikuu ya benki inayotumika sana Afrika Mashariki. Timu yetu ya muunganisho imekamilisha miunganisho na Temenos T24, Infosys Finacle, Oracle FlexCube, Mambu, na usanidi kadhaa wa M-PESA na Airtel Money — pamoja na maktaba za uoanishaji wa sehemu zilizoandikwa kwa kila mfumo.

Jadili mahitaji yako ya muunganisho na mfumo mkuu wa benki pamoja na timu yetu: Omba onyesho kupitia creodata.com/demo