Uwasilishaji wa goAML umekataliwa? Jinsi ya kuchunguza na kurekebisha makosa ya kawaida

Kukataliwa katika uwasilishaji wa kwanza ni jambo la kawaida kwa taasisi zinazoandaa mawasilisho ya goAML kwa mkono. Ikiwa taarifa yako ya miamala ya fedha taslimu (CTR) au taarifa ya miamala yenye mashaka (STR) imerudishwa hivi punde kutoka kwenye lango la Financial Reporting Centre (FRC) ya Kenya, hauko peke yako — lakini hilo halipunguzi usumbufu wa kurudia kazi, hasa muda wa mwisho wa kuwasilisha unapokaribia.

Mzunguko wa kukataliwa ni mojawapo ya mienendo yenye madhara makubwa zaidi katika shughuli za uzingatiaji wa AML (kupambana na utakatishaji fedha haramu). Mchambuzi anatumia saa mbili kuandaa uwasilishaji, unakataliwa, anatumia dakika 90 nyingine kuchunguza tatizo na kulirekebisha, unakataliwa tena kwa kosa tofauti, na siku mbili zinapita bila chochote kuwasilishwa huku muda wa mwisho ukikaribia. Wakati huo huo, meneja wa uzingatiaji anakabiliwa na maswali kuhusu kwa nini vipimo vya taasisi vya kuwasilisha kwa wakati vinazidi kudorora.

Mwongozo huu unavunja mzunguko huo. Unaeleza hasa jinsi ya kusoma taarifa ya kukataliwa kutoka FRC, unatoa marejeo yenye namba ya kutatua matatizo kwa sababu kumi zinazojitokeza zaidi za kukataliwa, unapitia mchakato wa kuwasilisha upya, na unakuonyesha jinsi ya kuzuia kukataliwa tangu mwanzo.

Kuelewa taarifa za kukataliwa za goAML

Kile ambacho FRC inakutumia uwasilishaji unaposhindwa

Lango la goAML la FRC linapokataa uwasilishaji, hutoa jibu la kukataliwa linalokufikia kwa mojawapo ya njia mbili, kulingana na aina ya hitilafu:

Ujumbe wa kosa katika ngazi ya lango: Ikiwa faili ina hitilafu kiasi kwamba lango haliwezi kuichanganua kabisa — faili iliyokatika, usimbaji (encoding) wa XML usio halali, upakiaji ulioharibika — lango hurejesha ujumbe wa kosa papo hapo kwenye skrini ya kupakia. Ujumbe huu ni mfupi na mara nyingi ni wa jumla (k.m. "Faili haikuweza kuchakatwa. Tafadhali kagua muundo wa faili."). Hauna misimbo ya kina ya makosa. Aina hii ya kosa inamaanisha kwamba XML yako haijaundwa ipasavyo (si well-formed) na inahitaji kukaguliwa katika ngazi ya muundo kabla hujaendelea kuchunguza makosa ya skima au ya kanuni za kibiashara.

Taarifa ya kukataliwa yenye muundo maalum (faili ya makosa ya XML): Kwa faili zinazoweza kuchanganuliwa lakini zinashindwa uthibitishaji, lango la FRC hutoa faili ya XML ya majibu ya makosa yenye muundo maalum. Faili hii ina rekodi moja au zaidi za makosa, na kila moja ina:

Msimbo wa kosa (k.m. ERR_001, ERR_012, ERR_045)
Kiwango cha uzito wa kosa (FATAL, ERROR, WARNING)
Ujumbe wa kosa kwa Kiingereza rahisi unaoeleza tatizo mahususi
Inapohusika, jina la elementi ya XML na thamani iliyosababisha hitilafu
Kwa makosa ya skima: mahali (XPath) pa elementi iliyoshindwa ndani ya mti wa XML

Pakua faili hii ya makosa kutoka kwenye historia ya uwasilishaji ya lango — ndiyo ramani yako ya uchunguzi. Usijaribu kurekebisha makosa kwa kutegemea skrini ya muhtasari ya lango pekee; maelezo ya kina yaliyo katika faili ya makosa ni muhimu ili kubaini tatizo kwa usahihi.

Kusoma misimbo ya makosa: makosa ya uthibitishaji wa skima dhidi ya ukiukaji wa kanuni za kibiashara

Makosa ya kukataliwa katika goAML yamegawanyika katika makundi mawili ya msingi, na kuyatofautisha ndiyo hatua ya kwanza ya uchunguzi:

Makosa ya uthibitishaji wa skima (kundi la ERR_001 hadi ERR_009): Haya yanamaanisha kwamba faili yako ya XML haifuati kanuni za kimuundo za skima ya XSD ya goAML v5.0.2. Sehemu ya tarehe ina thamani isiyo tarehe, sehemu ya desimali ina maandishi, elementi ya lazima haipo, au thamani iliyoorodheshwa haimo kwenye orodha inayoruhusiwa. Makosa ya skima husababishwa na mchakato wa kutengeneza XML — ama hatua ya kuandaa data ama hatua ya kujenga XML. Kwa kawaida ni rahisi kuyachunguza kwa sababu faili ya makosa hutaja elementi na thamani halisi iliyoshindwa.

Ukiukaji wa kanuni za kibiashara (kundi la ERR_010 hadi ERR_099): Makosa haya yanamaanisha kwamba XML yako ni halali kimuundo na inapita uthibitishaji wa skima, lakini inakiuka kanuni ya kibiashara iliyo mahususi kwa FRC ya Kenya. Namba ya National ID (kitambulisho cha taifa) iko katika muundo usio sahihi, kitambulisho cha taasisi inayowajibika kuripoti hakilingani na kumbukumbu za FRC, msimbo wa tawi haumo kwenye rejista ya Benki Kuu ya Kenya (CBK), au STR yenye kiashiria cha TF (ufadhili wa ugaidi) ina maelezo yasiyotosheleza. Makosa ya kanuni za kibiashara yanahitaji data yako ilinganishwe na vyanzo vya marejeo vya nje (kumbukumbu za FRC, rejista ya matawi ya CBK, orodha ya misimbo ya viashiria ya FRC) — marekebisho hayako katika muundo wa XML bali katika data yenyewe.

Kipaumbele: rekebisha makosa ya skima kwanza, kisha makosa ya kanuni za kibiashara

Ikiwa taarifa yako ya kukataliwa ina makosa ya skima na pia ukiukaji wa kanuni za kibiashara, rekebisha makosa ya skima kwanza. Sababu ni kwamba makosa ya skima yanaweza kuficha makosa ya kanuni za kibiashara — lango linaweza kuacha kutathmini kanuni za kibiashara baada ya kukutana na hitilafu ya skima. Faili yako ikishapita uthibitishaji wa skima, utaona orodha kamili ya ukiukaji wa kanuni za kibiashara badala ya sehemu yake tu.

Kosa la kawaida ni kurekebisha kosa moja la kanuni ya kibiashara linaloonekana na kuwasilisha upya, kisha kukuta kosa jingine la kanuni ya kibiashara katika jaribio linalofuata — kwa sababu kosa la skima lilikuwa limelificha. Shughulikia orodha nzima ya makosa kwa utaratibu kabla ya kuwasilisha upya.

Sababu 10 zinazojitokeza zaidi za kukataliwa (na marekebisho yake)

1. National ID haipo

Msimbo wa kosa: ERR_045 (ukiukaji wa kanuni ya kibiashara) Ujumbe wa kosa: "Namba ya National ID inahitajika kwa wahusika wenye id_type NATIONAL_ID." Chanzo cha tatizo: Namba ya National ID ya mteja haikupatikana katika rekodi ya Mjue Mteja Wako (KYC) wakati XML ilipotengenezwa, au iliwekwa kwenye sehemu isiyo sahihi ya XML. Vinginevyo, sehemu ya namba ya kitambulisho ilijazwa lakini ikaachwa kama maandishi matupu, jambo linalopita uthibitishaji wa skima lakini linashindwa ukaguzi wa kanuni ya kibiashara unaotaka maudhui ya lazima yasiwe tupu. Marekebisho: Pata namba ya National ID ya mteja kutoka kwenye mfumo wako wa KYC. Hakikisha ina tarakimu 7–8 hasa, bila herufi zozote zisizo tarakimu. Jaza elementi ya id_number katika XML na uthibitishe upya. Ikiwa National ID kweli haipo kwenye kumbukumbu zako za KYC, anzisha urekebishaji wa taarifa za KYC na uandike pengo hilo kabla ya kuwasilisha upya. Usiweke KRA PIN, namba ya pasipoti wala namba ya simu katika sehemu ya National ID badala yake.

2. Muundo wa tarehe si sahihi

Msimbo wa kosa: ERR_001 (kushindwa kwa uthibitishaji wa skima) Ujumbe wa kosa: "Elementi <transaction_date> ina thamani '25/03/2026' ambayo si xs:date halali." Chanzo cha tatizo: Sehemu za tarehe katika XML ya goAML lazima ziwe katika muundo wa ISO 8601: YYYY-MM-DD. Tarehe iliyohamishwa kutoka kwenye mfumo mkuu wa benki (core banking) katika muundo wa tarehe unaotumika Kenya (DD/MM/YYYY) au katika muundo chaguomsingi wa Excel (25-Mar-2026) itashindwa uthibitishaji wa skima. Kosa hili linahusu sehemu yoyote ya tarehe: transaction_date, report_date, date_of_birth, id_expiry_date. Marekebisho: Badilisha thamani zote za tarehe ziwe katika muundo wa YYYY-MM-DD kabla ya kuziweka kwenye XML. Ikiwa XML yako inatengenezwa na skripti au makro, ongeza hatua ya kusawazisha muundo wa tarehe wakati wa kuchopoa data — usitegemee mfumo chanzo kuhamisha data katika muundo sahihi. Pattern ya regex kwa tarehe halali ni ^\d{4}-\d{2}-\d{2}$. Miezi na siku zenye tarakimu moja lazima zitanguliwe na sifuri (k.m. 2026-03-05, si 2026-3-5).

3. Maelezo ni tupu

Msimbo wa kosa: ERR_001 (skima) au ERR_045 (kanuni ya kibiashara) Ujumbe wa kosa: "Elementi <reason> haipaswi kuwa tupu" au "Sehemu ya maelezo ya STR haikidhi masharti ya kiwango cha chini cha maudhui." Chanzo cha tatizo: Sehemu ya reason katika uwasilishaji wa STR ni tupu, ina nafasi tupu pekee, au ina maandishi ya kushikilia nafasi kama vile "maelezo yanasubiriwa" au "N/A." Hii ndiyo sababu ya kukataliwa inayoweza kuzuiwa kwa urahisi kuliko zote — inaonyesha kwamba ripoti ambayo haijakamilika iliwasilishwa. Marekebisho: Andika maelezo yenye maudhui ya kutosha kabla ya kuwasilisha. Kwa mwongozo kuhusu kile ambacho maelezo lazima yawe nacho na jinsi ya kuyapanga, tazama Jinsi ya kuandika maelezo ya STR katika goAML: mbinu bora. Kwa hali yoyote ile, usiwasilishe STR bila maelezo yaliyokamilika. Ikiwa shinikizo la muda linakutia wasiwasi, wasilisha ukiwa na maelezo mafupi lakini kamili yanayoshughulikia vipengele vitano vya lazima, kisha fuatilia kwa taarifa za nyongeza ikihitajika.

4. Maelezo ni mafupi mno (kesi za TF)

Msimbo wa kosa: ERR_045 (ukiukaji wa kanuni ya kibiashara) Ujumbe wa kosa: "STR yenye misimbo ya viashiria vya TF inahitaji maelezo ya kina zaidi. Maelezo ya sasa hayakidhi kiwango cha chini cha maudhui." Chanzo cha tatizo: STR ina msimbo mmoja au zaidi wa viashiria vya TF (ufadhili wa ugaidi), lakini maelezo katika sehemu ya reason yako chini ya kiwango cha chini cha maudhui ambacho FRC ya Kenya hutumia kwa ripoti zenye viashiria vya TF. Kiwango cha chini kinachotumika kivitendo ni takriban maneno 500 yanayoshughulikia uchambuzi kamili wa mbinu ya uhalifu (typology), ikiwemo hatari ya maeneo ya mamlaka husika, utambulisho wa wahusika wa upande wa pili na hatua zilizochukuliwa na taasisi. Marekebisho: Panua maelezo ili yakidhi viwango vya kuripoti TF. Maelezo ya TF lazima yajumuishe: utambulisho kamili wa mhusika, ufafanuzi wa kila muamala wenye mashaka, maelezo ya kwa nini TF inashukiwa (si utakatishaji fedha, yaani ML, pekee), kutaja kwa uwazi maeneo ya mamlaka yenye hatari kubwa au wahusika walio chini ya vikwazo wanaohusika, ufafanuzi wa mtiririko wa fedha kuvuka mipaka inapohusika, na hatua za taasisi, ikiwemo hatua yoyote iliyochukuliwa kuhusu akaunti na taarifa iliyotolewa kwa FRC. Ikiwa STR yako inahusisha kiashiria halisi cha TF, maelezo yanapaswa kufikia kwa kawaida maneno 500+ pale vipengele vyote vinavyohitajika vinaposhughulikiwa.

5. Msimbo wa sarafu si sahihi

Msimbo wa kosa: ERR_003 (kushindwa kwa uthibitishaji wa skima) Ujumbe wa kosa: "Thamani 'Ksh' katika elementi <transaction_currency> haimo kwenye orodha ya thamani zinazoruhusiwa (enumeration)." Chanzo cha tatizo: Sehemu ya transaction_currency inahitaji msimbo kamili wa sarafu wa herufi tatu wa ISO 4217. Njia mbadala zinazotumika sana nchini Kenya ambazo hushindwa ni pamoja na: Ksh, KSH, K.Sh, KE, KShs, Kshs. Zote zinatambulika kama shilingi ya Kenya kwa msomaji wa kibinadamu, lakini si halali katika enumeration ya skima. Marekebisho: Badilisha thamani zote za sarafu kwa misimbo kamili ya ISO 4217. Msimbo wa shilingi ya Kenya ni KES. Sarafu nyingine zinazoonekana mara nyingi katika miamala ya benki za Kenya: USD (dola ya Marekani), EUR (yuro), GBP (pauni ya Uingereza), UGX (shilingi ya Uganda), TZS (shilingi ya Tanzania). Ongeza jedwali la marejeo la misimbo ya sarafu katika mchakato wako wa kuandaa data ili kulazimisha misimbo sahihi tangu kwenye chanzo.

6. Aina ya muamala si sahihi

Msimbo wa kosa: ERR_003 (kushindwa kwa uthibitishaji wa skima) Ujumbe wa kosa: "Thamani 'CASH' katika elementi <transaction_type> haimo kwenye orodha ya thamani zinazoruhusiwa (enumeration)." Chanzo cha tatizo: Sehemu ya transaction_type hukubali tu thamani mahususi zilizoorodheshwa ambazo zimefafanuliwa katika XSD ya goAML. Thamani zisizo halali zinazoonekana mara nyingi katika mawasilisho ya CTR nchini Kenya ni pamoja na: CASH, DEPOSIT, WITHDRAWAL, CASH DEP, CASH WITH, TRANSFER. Hata thamani ambazo kusudi lake ni sahihi waziwazi hushindwa ikiwa hazilingani kikamilifu. Marekebisho: Tumia tu thamani kamili za enumeration zinazoruhusiwa na skima. Kwa mawasilisho ya CTR kwa FRC ya Kenya, thamani halali za transaction_type ni: CASH_DEPOSIT, CASH_WITHDRAWAL, CURRENCY_EXCHANGE. Usitumie vifupisho, nafasi ndani ya thamani, wala tofauti za herufi kubwa na ndogo. Ikiwa mfumo wako mkuu wa benki unahamisha misimbo ya aina ya muamala katika muundo tofauti, ongeza jedwali la kuoanisha misimbo katika mchakato wako wa kutengeneza XML.

7. Kitambulisho cha taasisi inayoripoti hakipo

Msimbo wa kosa: ERR_045 (ukiukaji wa kanuni ya kibiashara) Ujumbe wa kosa: "Kitambulisho cha taasisi inayowajibika kuripoti hakilingani na rejista ya FRC. Sehemu: reporting_entity_id." Chanzo cha tatizo: Namba ya usajili wa taasisi katika FRC (FRC Entity Registration Number) iliyo katika XML ama hailingani na namba iliyosajiliwa na FRC, ama sehemu hiyo haipo au ni tupu. Sababu za kawaida ni pamoja na: makosa ya unakili katika namba ya usajili, tofauti katika muundo wa jina (skima inahitaji jina halisi kama lilivyosajiliwa), na mawasilisho yaliyofanywa kwa namba ya FRC ya kampuni tanzu wakati namba ya kampuni mama ndiyo iliyokusudiwa (au kinyume chake). Marekebisho: Pata FRC Entity Registration Number ya taasisi yako moja kwa moja kutoka kwenye cheti chako cha usajili cha FRC — hati halisi, si namba unayoikumbuka. Inakili herufi kwa herufi katika XML yako. Muundo wake ni FRC/INST/YYYY/NNNN. Hakikisha pia kwamba reporting_entity_name katika XML inalingana kikamilifu na jina la taasisi lililosajiliwa. Hifadhi namba sahihi katika faili ya usanidi wa kutengeneza XML ili kuondoa makosa ya kuiingiza upya kila mara.

8. Namba ya kumbukumbu ya ripoti imejirudia

Msimbo wa kosa: ERR_008 (ukiukaji wa kanuni ya kibiashara) Ujumbe wa kosa: "Namba ya kumbukumbu ya ripoti [thamani] imekwisha kuwasilishwa awali. Kila uwasilishaji lazima uwe na namba ya kumbukumbu ya kipekee." Chanzo cha tatizo: Taasisi yako iliwasilisha awali ripoti yenye thamani ileile ya report_reference. Hili linaweza kutokea pale: ripoti iliyokataliwa inapowasilishwa upya kwa kutumia kipengele cha Resubmit lakini namba mpya ya kumbukumbu ikatengenezwa kimakosa, ripoti ileile inapowasilishwa mara mbili kwa sababu ya mkanganyiko katika kutumia lango, au mantiki yako ya kutengeneza namba za kumbukumbu haihakikishi upekee (k.m. kutumia namba ya kumbukumbu yenye tarehe pekee bila namba ya mfuatano). Marekebisho unapowasilisha upya: Unapowasilisha upya ripoti iliyokataliwa awali, tumia kipengele cha Resubmit cha lango na utaje kitambulisho cha uwasilishaji wa awali — usibadilishe namba ya kumbukumbu ya ripoti. FRC hufuatilia masahihisho chini ya namba ya kumbukumbu ya awali. Marekebisho kwa uwasilishaji uliorudiwa kweli: Tengeneza namba mpya ya kumbukumbu ya kipekee. Boresha utaratibu wako wa kutengeneza namba za kumbukumbu ili ujumuishe namba ya mfuatano inayoongezeka (k.m. NSBK-CTR-20260325-004) badala ya namba ya kumbukumbu yenye tarehe pekee au inayotokana na hash, ambayo inaweza kugongana na nyingine.

9. Msimbo wa kiashiria si sahihi

Msimbo wa kosa: ERR_045 (ukiukaji wa kanuni ya kibiashara) Ujumbe wa kosa: "Msimbo wa kiashiria [thamani] hautambuliki katika orodha ya marejeo ya viashiria ya FRC ya Kenya." Chanzo cha tatizo: Sehemu ya indicator_codes ina msimbo mmoja au zaidi ambao haupo katika orodha ya sasa ya marejeo ya misimbo ya viashiria ya FRC. Hili hutokea pale: mchambuzi anapoandika misimbo ya viashiria kwa mkono na kufanya kosa la unakili, misimbo kutoka kwenye utekelezaji wa FIU (kitengo cha taarifa za kifedha) nyingine inapotumika (misimbo ya jumla ya FATF dhidi ya misimbo ya FRC ya Kenya), au FRC imesasisha orodha yake ya misimbo ya viashiria na orodha ya marejeo ya taasisi yako haijasasishwa. Marekebisho: Pata orodha ya sasa ya marejeo ya misimbo ya viashiria ya FRC ya Kenya moja kwa moja kutoka FRC au kutoka kwenye sehemu ya data za marejeo ya lango la goAML. Badilisha misimbo yote isiyo halali kwa misimbo sahihi kutoka kwenye orodha ya sasa. Ikiwa unatunza jedwali la marejeo la misimbo ya viashiria katika mfumo wako wa uzingatiaji, lisasishe kulingana na orodha ya sasa ya FRC. Fikiria kuongeza uthibitishaji wa misimbo ya viashiria katika orodha hakiki yako ya kabla ya kuwasilisha.

10. Muundo wa namba ya akaunti haulingani

Msimbo wa kosa: ERR_045 (ukiukaji wa kanuni ya kibiashara) Ujumbe wa kosa: "Muundo wa namba ya akaunti haulingani na pattern inayotarajiwa kwa taasisi inayoripoti." Chanzo cha tatizo: Sehemu ya account_number ina thamani isiyofuata muundo wa namba ya akaunti ambao taasisi yako imesajili kwa FRC au CBK. Hili linaweza kutokea pale namba za akaunti kutoka kwenye mifumo tofauti zinapochanganywa (muundo wa namba ya akaunti wa mfumo mkuu wa benki dhidi ya muundo wa akaunti wa CBK dhidi ya muundo wa kimataifa wa IBAN), pale sifuri za mwanzo zinapoondolewa wakati wa kuhamisha data, au pale namba za akaunti zinapojumuisha misimbo ya tawi au ya bidhaa ambayo si sehemu ya namba halisi ya akaunti. Marekebisho: Thibitisha muundo halisi wa namba ya akaunti ambao taasisi yako imesajili kwa FRC — kwa kawaida huu ni muundo uleule unaotumika katika ripoti za kisheria kwa CBK. Tumia muundo unaofanana katika mchakato wako wote wa kutengeneza XML: ikiwa namba zako za akaunti zina tarakimu 13 zikiwemo sifuri za mwanzo, hakikisha uhamishaji wa data unazihifadhi sifuri hizo (tatizo la kawaida la Excel). Ikiwa mfumo wako huhifadhi namba za akaunti zikiwa na misimbo ya tawi au ya bidhaa ndani yake, ondoa sehemu hizo kabla ya kujumuisha namba ya akaunti katika XML ya CTR/STR.

Jinsi ya kuwasilisha upya baada ya kurekebisha makosa

Mchakato wa kuwasilisha upya kupitia lango la FRC

Mchakato sahihi wa kuwasilisha upya unategemea iwapo unasahihisha uwasilishaji uliokataliwa au unawasilisha marekebisho ya uwasilishaji uliokubaliwa:

Kwa mawasilisho yaliyokataliwa: Nenda kwenye historia yako ya uwasilishaji katika lango la FRC na utafute uwasilishaji uliokataliwa kwa namba yake ya kumbukumbu. Tumia chaguo la Resubmit (si New Report) na upakie faili yako ya XML iliyosahihishwa. Lango huunganisha faili iliyosahihishwa na rekodi ya uwasilishaji wa awali, na hivyo kuhifadhi mfuatano wa muda wa uwasilishaji kwa madhumuni ya kuzingatia muda wa mwisho. Usibadilishe thamani ya report_reference katika XML iliyosahihishwa — FRC inahitaji kuoanisha ripoti iliyosahihishwa na ile ya awali.

Kwa marekebisho ya mawasilisho yaliyokubaliwa: Ikiwa uwasilishaji uliokubaliwa ulikuwa na kosa ambalo unaligundua baada ya kukubaliwa, wasiliana na FRC moja kwa moja (tazama sehemu ya kupeleka suala kwa FRC hapa chini) kabla ya kujaribu kuwasilisha marekebisho. FRC itakushauri iwapo marekebisho kupitia lango, STR ya nyongeza au masahihisho rasmi ya maandishi ndiyo yanayofaa, kulingana na aina ya kosa.

Kuwasilisha upya ndani ya muda wa mwisho — je, bado ni kwa wakati?

Chini ya POCAMLA (Proceeds of Crime and Anti-Money Laundering Act) na kanuni zake, CTR (miamala ya fedha taslimu ya US$15,000 au zaidi) lazima ziwasilishwe kufikia Ijumaa ya wiki ambayo muamala uliozua wajibu huo ulifanyika (kifungu cha 44(6) na kanuni ya 40). STR lazima ziwasilishwe ndani ya siku mbili tangu tarehe ambayo mashaka yalijitokeza (kifungu cha 44(2)). FRC hupima kuwasilisha kwa wakati kuanzia tarehe ya tukio lililozua wajibu hadi tarehe ya uwasilishaji wa kwanza, si hadi tarehe ya kuwasilisha upya kwa mafanikio.

Hii inamaanisha kwamba ikiwa jaribio lako la kwanza la kuwasilisha lilikuwa ndani ya muda wa mwisho lakini likakataliwa, taasisi yako bado imejaribu kuwasilisha kwa wakati. Kukataliwa na kuwasilisha upya kunaandikwa katika historia ya uwasilishaji ya lango. Hata hivyo, ikiwa jaribio lako la kwanza la kuwasilisha liko nje ya muda wa mwisho kwa sababu ya ucheleweshaji wa ndani — si kwa sababu ya kukataliwa na kuwasilisha upya — hakuna kinga yoyote. Wasilisha kwa wakati, rekebisha makosa kwa wakati, na uwasilishe upya haraka iwezekanavyo.

Hifadhi kumbukumbu ya muhuri wa muda (timestamp) wa jaribio lako la kwanza la kuwasilisha. Katika ukaguzi wa mdhibiti au ukaguzi wa AML, muhuri huu wa muda unaonyesha nia ya kuwasilisha kwa wakati hata pale uwasilishaji wa awali ulipokataliwa.

Kuandika kukataliwa na marekebisho katika kumbukumbu zako za ukaguzi za uzingatiaji

Kila uwasilishaji uliokataliwa na kila uwasilishaji upya unaofuata lazima viandikwe katika kumbukumbu za uzingatiaji za taasisi yako. Kumbukumbu hizo zinapaswa kujumuisha:

Namba ya kumbukumbu ya uwasilishaji na tarehe ya uwasilishaji wa ripoti iliyokataliwa
Misimbo ya makosa iliyopokelewa na jumbe za makosa
Masahihisho mahususi ya data yaliyofanywa na chanzo cha data iliyosahihishwa
Tarehe na namba ya kumbukumbu ya uwasilishaji upya uliofanikiwa
Jina la afisa uzingatiaji aliyefanya masahihisho na jina la afisa aliyeidhinisha kuwasilisha upya

Kumbukumbu hizi zina malengo mawili: zinaonyesha kwa wadhibiti kwamba taasisi yako inachukulia ubora wa mawasilisho kwa uzito na inashughulikia kukataliwa kwa utaratibu, na zinatoa mfuatano wa ushahidi ambao ni muhimu ikiwa FRC itauliza maswali kuhusu ripoti mahususi miezi au miaka kadhaa baadaye.

Kuzuia kukataliwa kabla hakujatokea

Orodha hakiki ya uthibitishaji kabla ya kuwasilisha (ukaguzi 10)

Pitia orodha hakiki hii kwa kila CTR au STR kabla ya kupakia kwenye lango la FRC:

Ukaguzi wa muundo wa tarehe: Sehemu zote za tarehe ziko katika muundo wa YYYY-MM-DD bila kuacha hata moja.
Ukaguzi wa National ID: Rekodi zote za wahusika raia wa Kenya zina National ID ya tarakimu 7–8 katika sehemu ya id_number.
Ukaguzi wa msimbo wa sarafu: Thamani zote za transaction_currency ni misimbo kamili ya herufi tatu ya ISO 4217 (KES, USD, EUR, n.k.).
Ukaguzi wa aina ya muamala: Thamani zote za transaction_type zinatoka kwenye enumeration inayoruhusiwa.
Upekee wa namba ya kumbukumbu ya ripoti: report_reference haijatumika katika uwasilishaji wowote wa awali.
Ukaguzi wa kitambulisho cha taasisi inayoripoti: reporting_entity_id inalingana kikamilifu na cheti chako cha usajili cha FRC.
Ukaguzi wa msimbo wa tawi: Thamani zote za branch_code zinalingana na matawi ya taasisi yako yaliyosajiliwa na CBK.
Ukamilifu wa maelezo (STR): Sehemu ya reason ina maelezo yenye maudhui ya kutosha yanayoshughulikia vipengele vyote vitano vya lazima.
Ukaguzi wa misimbo ya viashiria (STR): Thamani zote za indicator_codes zimo kwenye orodha ya sasa ya marejeo ya viashiria ya FRC.
Uthibitishaji wa skima ya XSD: Pitisha XML kwenye kikagua XSD kilicho kwenye kompyuta yako dhidi ya skima ya XSD ya goAML v5.0.2 kabla ya kupakia.

Kwa nini injini ya uthibitishaji hunasa makosa kabla FRC haijayaona

Injini ya uthibitishaji iliyojengwa mahususi kwa goAML hutumia ngazi zote mbili za uthibitishaji — kukidhi skima ya XSD na kuzingatia kanuni za kibiashara za FRC ya Kenya — kwenye faili yako ya XML kabla haijatoka kabisa katika taasisi yako. Injini ya uthibitishaji inajua:

Kila sehemu ya lazima na muundo wake unaotakiwa
Kila thamani ya enumeration katika skima
Kanuni ya FRC ya Kenya kuhusu muundo wa National ID
Rejista ya misimbo ya matawi ya CBK
Namba ya usajili wa taasisi yako katika FRC
Orodha ya sasa ya marejeo ya misimbo ya viashiria ya FRC
Kiwango cha chini cha maudhui ya maelezo ya TF

Injini inapogundua kosa, husimamisha mtiririko wa kazi wa uwasilishaji na kuonyesha kosa hilo pamoja na maelezo kwa Kiingereza rahisi na sahihisho mahususi la data linalohitajika. Mchambuzi wa uzingatiaji hurekebisha data, hutengeneza XML upya, na injini ya uthibitishaji huendeshwa tena. Ni faili inayopita ukaguzi wote pekee ndiyo huandaliwa tayari kwa kuwasilishwa.

Mbinu hii inahamisha uthibitishaji kutoka kuwa shughuli ya uchunguzi baada ya kukataliwa hadi kuwa kituo cha ukaguzi wa ubora kabla ya kuwasilisha. Matokeo yake: makosa hugunduliwa na kurekebishwa ndani ya mchakato wako mwenyewe, kabla lango halijaiona faili hata kidogo.

Kutoka ukataaji wa kila mara hadi ukataaji karibu sifuri kwa uthibitishaji wa kiotomatiki

Kuhama kutoka kutengeneza XML kwa mkono hadi uthibitishaji wa kiotomatiki hubadilisha mahali makosa yanapokamatwa. Ukaguzi ambao lango la FRC lingefanya linapopokea faili hufanyika kwanza ndani ya taasisi yako, hivyo faili yenye kosa la skima au la kanuni ya kibiashara haifiki kamwe kwenye lango. Mzunguko wa kurudia kazi hupungua hadi kusahihisha data kwenye chanzo chake, shinikizo la muda wa mwisho linalotokana na kuwasilisha upya mara kwa mara hupungua, na wachambuzi wa uzingatiaji huelekeza muda wao kutoka kutatua hitilafu za XML hadi kazi halisi ya uzingatiaji — kupitia kesi, kuchambua mienendo, na kuandaa maelezo bora.

Kiwango kikubwa cha kukataliwa si sifa isiyoepukika ya kuripoti kupitia goAML. Ni matokeo yanayotabirika ya kutumia mchakato wa mkono kwa kiwango cha kiufundi cha hali ya juu. Uthibitishaji wa kiotomatiki hufanya mafanikio katika jaribio la kwanza kuwa jambo la kawaida.

Wakati wa kupeleka suala moja kwa moja kwa FRC

Ikiwa lango halitoi ujumbe wa kosa ulio wazi

Ikiwa lango la FRC linajibu uwasilishaji wako kwa ujumbe wa kosa wa jumla ("uwasilishaji haukuweza kuchakatwa") bila kutoa faili ya makosa yenye muundo maalum, huenda XML yako ina hitilafu kubwa kiasi kwamba lango haliwezi kuichanganua. Katika hali hii:

Thibitisha XML yako dhidi ya skima ya XSD ya goAML v5.0.2 kwa kutumia kikagua kilicho kwenye kompyuta yako (xmllint, XML Notepad, au kikagua cha mtandaoni katika freeformatter.com)
Hakikisha faili yako ya XML imesimbwa kwa UTF-8 bila herufi za alama ya mpangilio wa baiti (BOM)
Hakiki kwamba kiendelezi cha faili ni .xml (si .txt, .csv wala muundo mwingine wowote)
Thibitisha kwamba faili ilitengenezwa bila herufi za binary au herufi tupu (null) zilizoingizwa na mchakato wa kuhamisha data

Ikiwa faili inapita uthibitishaji kwenye kompyuta yako lakini lango bado linatoa kosa la jumla, peleka suala hilo kwa dawati la msaada la FRC.

Ikiwa XML yako halali inakataliwa (huenda ni tatizo la lango la FRC)

Mara kwa mara, lango la FRC hukumbwa na matatizo ya kiufundi yanayosababisha mawasilisho halali kukataliwa kimakosa. Dalili kwamba huenda hili linatokea ni pamoja na:

Taasisi kadhaa kuripoti aina ileile ya kukataliwa kwa wakati mmoja
Msimbo wa kosa la kukataliwa haujulikani na haujaelezwa katika miongozo ya FRC inayopatikana
Uwasilishaji uliopita uthibitishaji wote wa kabla ya kuwasilisha, na ambao umewahi kuwasilishwa kwa mafanikio hapo awali (muundo uleule, taasisi ileile), unakataliwa kwa mara ya kwanza

Ikiwa unashuku tatizo liko upande wa lango, andika kwa ukamilifu ushahidi wako wa uthibitishaji wa kabla ya kuwasilisha kabla ya kuwasiliana na FRC. Kuweza kuonyesha kwamba faili yako inapita uthibitishaji wa XSD huimarisha kwa kiasi kikubwa hoja yako unapopeleka suala hilo.

Mawasiliano ya dawati la msaada la FRC

Kwa matatizo ya kiufundi ya uwasilishaji yasiyoweza kutatuliwa kupitia zana za kujihudumia za lango, wasiliana moja kwa moja na Financial Reporting Centre ya Kenya:

Tovuti: frc.go.ke (tumia maelezo ya mawasiliano yaliyochapishwa humo)
Lango la goAML: goaml.frc.go.ke

Unapowasiliana na FRC kuhusu tatizo mahususi la uwasilishaji, jumuisha: FRC Entity Registration Number ya taasisi yako, namba ya kumbukumbu ya uwasilishaji, misimbo ya makosa iliyopokelewa, na maelezo ya hatua ambazo tayari umechukua kuchunguza na kutatua tatizo. Muktadha huu huliwezesha dawati la msaada la FRC kukusaidia kwa haraka zaidi.

Komesha mzunguko wa kukataliwa kabisa

Kila uwasilishaji wa goAML unaokataliwa unaweza kuzuiwa. Makosa yanayosababisha kukataliwa — miundo isiyo sahihi ya tarehe, National ID zinazokosekana, thamani za enumeration zisizo halali, maelezo matupu, namba za kumbukumbu zilizojirudia — hayatokani na utata mgumu wa kanuni za udhibiti. Yanatokana na mchakato wa kushughulikia data na kutengeneza XML kwa mkono ambao haufai kwa usahihi unaodaiwa na skima ya goAML.

Jukwaa la goAML la Creodata huvunja mzunguko wa kukataliwa kwa kuendesha kiotomatiki ngazi zote mbili za uthibitishaji — kukidhi skima ya XSD na kuzingatia kanuni za kibiashara za FRC ya Kenya — kabla faili yoyote haijawasilishwa kwenye lango la FRC. Injini ya jukwaa ya uthibitishaji wa kabla ya kuwasilisha huendesha kila ukaguzi ulio katika ukurasa huu kiotomatiki, kila mara, kwa kila ripoti.

Unapohama kutoka mchakato wa kuwasilisha kwa mkono hadi jukwaa la kiotomatiki, kukataliwa kwa sababu ya skima na kanuni za kibiashara kunaacha kuwa jambo la kawaida — kwa sababu mashine hukagua skima kila mara, bila uchovu, bila kuruka hatua, na bila shinikizo la muda wa mwisho kusababisha njia za mkato.

Tazama jinsi jukwaa la goAML la Creodata linavyoshusha ukataaji katika uwasilishaji wa kwanza hadi karibu sifuri.

Omba onyesho → https://www.creodata.com/demo

Makala zinazohusiana: