SWIFT

Uhamisho wa SWIFT na Mawasiliano kwa Ujumbe wa MT na MX

SWIFT (Society for Worldwide Interbank Financial Telecommunication) ni mtandao salama wa ujumbe unaowawezesha taasisi za kifedha, kama vile benki, kutuma na kupokea ujumbe sanifu kuhusu miamala ya kifedha, kama vile maagizo ya malipo na uthibitisho. SWIFT haihifadhi akaunti wala kuhamisha fedha; inatoa jukwaa salama na la kuaminika la kubadilishana taarifa tu.

Uhamisho wa kawaida wa SWIFT hutumia mfululizo wa aina sanifu za jumbe zinazojulikana kama jumbe za MT (Message Type). Jumbe hizi zina miundo na sehemu zilizoainishwa awali, hivyo kuhakikisha kwamba taasisi za kifedha zinaweza kuelewa na kuchakata kwa urahisi taarifa zilizomo.

Ujumbe wa MX (ISO 20022) ni kiwango kipya cha ujumbe wa kifedha kinachotegemea XML (eXtensible Markup Language). Hutoa muundo tajiri na uliopangiliwa zaidi, unaowezesha ubadilishanaji bora wa data na usindikaji wa moja kwa moja bila uingiliaji wa mikono. Ujumbe wa MX unachukua nafasi ya ujumbe wa MT hatua kwa hatua katika mtandao wa SWIFT, kwa lengo la kuboresha ushirikiano wa mifumo na ushughulikiaji wa data.

Ingawa uhamishaji wa jadi wa SWIFT umekuwa msingi wa malipo ya kimataifa kwa miongo kadhaa, una mapungufu kadhaa, ikiwemo uwazi mdogo, muda mrefu wa uchakataji, na data isiyopangiliwa.

Swift 103+ STP (Uchakataji Usiokatizwa, Straight Through Processing)

Swift 103+ STP ilikuwa muundo wa zamani wa MT ulioboreshwa kwa Straight Through Processing (STP) (uchakataji wa moja kwa moja bila kuingilia kati); tangu kumalizika kwa kipindi cha uwepo sambamba wa miundo, jukumu lake limechukuliwa na mwongozo wa matumizi wa STP wa pacs.008. STP huwezesha mchakato mzima wa malipo, kuanzia uanzishaji hadi ulipaji wa mwisho, kutekelezwa kielektroniki bila haja ya kuingilia kati kwa mikono.

Vipengele vya Ziada:

1. Muundo Sanifu: Unahitaji kuzingatiwa kikamilifu kwa muundo sanifu, hivyo kupunguza makosa na ucheleweshaji.
2. Uchakataji wa Kiotomatiki: Miamala huchakatwa kiotomatiki, hivyo kuhakikisha uchakataji wa haraka na madhubuti zaidi.
3. Kupungua kwa Uingiliaji wa Mikono: Uhitaji wa kuingiza na kuhakiki data kwa mikono unapunguzwa, hivyo kupunguza hatari ya makosa na ucheleweshaji.
4. Malipo ya Haraka Zaidi: Miamala hukamilishwa kwa haraka zaidi kuliko mbinu za jadi.

Mambo ya kuzingatia kuhusu STP:

1. Uingizaji Sahihi wa Data: Data lazima iingizwe kwa usahihi ili kuepuka ucheleweshaji au kukataliwa.
2. Kuzingatia Mahitaji ya Umbizo: Benki lazima zihakikishe kuwa mahitaji ya umbizo la 103+ STP yanafuatwa kikamilifu.
3. Programu na Mifumo: Benki zinahitaji kuwa na programu na mifumo inayofaa ili kushughulikia STP kwa ufanisi

Ni muhimu kutofautisha kati ya utumaji wa ujumbe na ukamilishaji wa malipo (settlement). SWIFT hutuma ujumbe wa kifedha ulio na muundo maalum kati ya taasisi, lakini yenyewe haihamishi fedha wala kutunza salio. Uthibitisho wa SWIFT, ukijumuisha ujumbe wa pacs.008, ni halali tu pale unapolingana na muamala halisi uliosindikwa na kupatanishwa katika mifumo ya kibenki ya taasisi zinazohusika.

Hati yoyote ya SWIFT inayojitegemea, picha ya skrini, au ujumbe unaowasilishwa bila uthibitisho wa kitaasisi haipaswi kuchukuliwa kuwa ushahidi wa kukamilika kwa malipo ya mwisho (settlement).

Uhamishaji wa fedha kupitia SWIFT gpi.

SWIFT gpi (Global Payments Innovation):

SWIFT gpi, iliyozinduliwa mwaka 2017, ni mpango uliobuniwa kushughulikia mapungufu ya uhamishaji wa jadi wa SWIFT kwa kuimarisha kasi, uwazi na uwezo wa kufuatilia malipo ya kuvuka mipaka. SWIFT gpi hutumia miundo iliyopo ya ujumbe ya MT na MX ili kuboresha huduma za malipo. Sifa kuu za SWIFT gpi ni pamoja na:

• Malipo ya haraka zaidi: gpi hurahisisha michakato na kuweka makubaliano makali zaidi ya viwango vya huduma (SLA) kati ya benki, hivyo kupunguza muda wa miamala, mara nyingi hadi dakika au sekunde.
• Ufuatiliaji wa malipo: gpi Tracker huwezesha kufuatilia miamala kwa wakati halisi, na hivyo kuboresha uwazi na kupunguza uchunguzi wa mikono.
• Uwazi wa ada: Benki zinaweza kuwapa wateja taarifa kuhusu ada za miamala mapema, na hivyo kuwawezesha kufanya maamuzi bora zaidi.
• Data tajiri zaidi: gpi huwezesha ubadilishanaji wa taarifa za kina zaidi na zilizopangiliwa, na hivyo kuwezesha upatanisho bora wa hesabu na uzingatiaji wa kanuni za udhibiti.

SWIFT gpi hushughulikia mapungufu ya uhamishaji wa jadi wa SWIFT kwa kuboresha malipo ya kuvuka mipaka kupitia ufuatiliaji wa hatua zote, uchakataji wa haraka zaidi, na data iliyo kamili zaidi.

Vigezo Muhimu kwa Washiriki Wasio wa SWIFT gpi

Mshiriki asiye wa SWIFT gpi (kwa mfano, benki au taasisi ya kifedha isiyojiunga moja kwa moja na gpi) anapotuma maelekezo ya malipo kwa benki mshiriki wa gpi, benki hiyo ya gpi inaweza kuyabadilisha kuwa miundo ya ujumbe ya SWIFT inayohitajika (pacs.008 kwa uhamishaji wa mikopo wa wateja, pacs.009 COV kwa uhamishaji wa bima (cover transfers) na pacs.009 kwa uhamishaji wa mikopo wa taasisi za kifedha). Ubadilishaji huu huwezesha uchakataji na ufuatiliaji ndani ya mtandao wa gpi, mradi maelekezo yawe na data ya kutosha kujaza sehemu za lazima na kuzingatia kanuni za gpi, kama vile uwezo wa kufuatilia muamala kuanzia mwanzo hadi mwisho.

Washiriki wasio wa gpi kwa kawaida hutoa vigezo hivi kupitia mifumo ya malipo ya ndani ya nchi, API, au miundo ya zamani, na benki ya gpi hushughulikia nyongeza mahususi za gpi (kwa mfano, kutengeneza UETR iwapo haikutolewa, ingawa kuiwasilisha ni hiari kwa taasisi zisizo za gpi). Mahitaji kamili yanaweza kutofautiana kulingana na mamlaka ya kisheria, sarafu na makubaliano baina ya pande mbili, lakini vigezo vya msingi vinatokana na miongozo ya CBPR+ (Cross-Border Payments and Reporting Plus) na viwango vya ISO 20022. Tangu kumalizika kwa kipindi cha kuishi pamoja kwa mifumo hiyo tarehe 22 Novemba 2025, maagizo ya malipo ya kimataifa hubadilishwa kwa muundo wa ISO 20022; marejeo ya sehemu za MT yaliyotolewa hapa chini ni kwa ajili ya mwongozo tu.
1. Utambulisho wa Wahusika (Maelezo ya Mdaiwa na Mdai)
Vigezo hivi hutambulisha mwanzilishi wa malipo na mnufaika, na kuhakikisha kuzingatia Pendekezo la 16 la FATF kuhusu mahitaji ya kanuni ya usafiri (travel rule).

• Mdaiwa/Mteja Anayeagiza: Jina kamili, anwani iliyopangiliwa (mtaa, jiji, msimbo wa posta, nchi), na utambulisho wa akaunti (k.m., IBAN au nambari ya akaunti). Katika MT 103/MT 202 COV ya awali, hii inalingana na Field 50a; kwa pacs.008/pacs.009, inalingana na <Dbtr> na <DbtrAcct>.
• Mdai/Mteja Mnufaika: Jina kamili, anwani iliyopangiliwa, na utambulisho wa akaunti. Inalingana na Field 59a katika MT 103/MT 202 COV ya awali; <Cdtr> na <CdtrAcct> katika pacs.008/pacs.009.
• Mdaiwa/Mdai wa Mwisho (ikiwa inatumika): Ikiwa ni tofauti na pande kuu, jumuisha maelezo yao kwa uwazi zaidi (si lazima, lakini inapendekezwa kwa ufuatiliaji wa gpi). Inalingana na <UltmtDbtr>/<UltmtCdtr> katika pacs.008/pacs.009.

Kwa nini inahitajika: Inawezesha uelekezaji sahihi na ukaguzi wa kisheria na kikanuni; taarifa pungufu zinaweza kusababisha kukataliwa au ucheleweshaji.

2. Taarifa za Wakala na Njia ya Malipo
Hubainisha taasisi za kifedha zinazohusika katika mnyororo huo.

• Wakala wa Mdaiwa (Debtor Agent): BIC (Bank Identifier Code) au kitambulisho kingine cha benki inayotuma. Hulingana na Uga 52a katika MT 103 ya awali; <DbtrAgt> katika pacs.008/pacs.009.
• Wakala wa Mdai (Creditor Agent): BIC ya benki inayopokea. Inalingana na Sehemu 57a katika MT 103/MT 202 COV ya zamani; <CdtrAgt> katika pacs.008/pacs.009.
• Mawakala wa Kati (ikiwa wanajulikana): BIC za benki zozote zinazowakilisha (hadi ngazi 3). Inalingana na Field 56a katika MT ya awali; <IntrmyAgt1-3> katika pacs.008/pacs.009.
• Mawakala Wanaoelekeza/Wanaoelekezwa: BIC za mtumaji/mpokeaji wa karibu katika mnyororo. Si lazima, lakini husaidia katika njia za mfululizo au za cover.
• Mawakala Waliotoa Maelekezo Hapo Awali (inapohusika): Kwa minyororo yenye hatua nyingi, hadi mawakala 3 wa awali.

Kwa nini inahitajika: Huhakikisha upitishaji sahihi kupitia benki za kati; tumia BICFI badala ya majina kwa usahihi zaidi katika pacs.009 COV.

3. Maelezo ya Muamala
Vipengele vya msingi vya kifedha kwa ajili ya malipo na ukamilishaji wa muamala.

• Kiasi na Sarafu: Kiasi cha usuluhishi kati ya benki na msimbo wa sarafu wa ISO 4217 (mfano, USD, EUR). Hulingana na Sehemu ya 32A katika MT 103/MT 202 COV ya awali; <IntrBkSttlmAmt> katika pacs.008/pacs.009.
• Kiasi Kilichoagizwa (ikiwa ni tofauti): Kiasi cha awali kabla ya makato.
• Tarehe ya Malipo Kati ya Benki: Tarehe ya thamani ya malipo. Inaelekeza sehemu ya Field 32A katika MT; <IntrBkSttlmDt> katika pacs.008/pacs.009.
• Njia ya Malipo: Onyesha kama ni kupitia RTGS (CLRG), cover (COVE), au wakala (INDA/INGA). Hakuna kielelezo sawia cha moja kwa moja katika MT, ingawa kinadokezwa.

Kwa nini inahitajika: Hufafanua uhamishaji wa thamani; ni ya lazima kwa miundo yote.

4. Vitambulisho vya Rejea na Ufuatiliaji
Kwa ajili ya ufuatiliaji, hasa katika gpi.

• Utambulisho wa Mwanzo hadi Mwisho: Rejeo linalounganisha mnyororo mzima (kwa mfano, kitambulisho cha ankara au muamala). <EndToEndId> katika pacs.008/pacs.009.
• Utambulisho wa Maelekezo: Rejea ya mtumaji (hadi herufi 16 katika MT). Inalingana na Field 20 katika MT ya awali; <InstrId> katika pacs.008/pacs.009.
• Unique End-to-End Transaction Reference (UETR): UUID kwa ajili ya ufuatiliaji wa mwanzo hadi mwisho. Ni ya lazima katika pacs.008/pacs.009 na, katika MT 103/MT 202 za awali, katika Field 121; iwapo njia ya uanzishaji haitoi kitambulisho hiki, benki ya kwanza ya Swift katika mnyororo huzalisha.
• Utambulisho wa Muamala: Kumbukumbu ya ziada ya ndani.

Kwa nini inahitajika: Huwezesha ufuatiliaji na uunganishaji wa gpi (mfano, pacs.008 na pacs.009 COV); UETR ni muhimu kwa uthibitisho wa jumla.

5. Madhumuni na Taarifa za Huduma
Huainisha aina ya malipo.

• Madhumuni na Kategoria Misimbo ya madhumuni: Misimbo ya ISO (k.m., SALA kwa mshahara) inayoonyesha asili ya muamala. Inahitajika katika baadhi ya njia za malipo; <Purp> na <CtgyPurp> katika pacs.008.
• Msimbo wa Kiwango cha Huduma: Hubainisha huduma ya gpi (kwa mfano, G001 kwa uhamisho wa mkopo wa mteja wa gpi); benki zisizo za gpi hazipaswi kujumuisha misimbo mahsusi ya gpi isipokuwa imekubaliwa. Unalingana na Field 23E katika MT; <SvcLvl> katika pacs.008/pacs.009.
• Msimbo wa Chombo cha Ndani (Local Instrument Code): Kwa mipango maalum (kwa mfano, uhamishaji ndani ya kundi la kampuni).

Kwa nini inahitajika: Huhakikisha uzingatiaji wa kanuni na kipaumbele cha uchakataji; inazidi kuwa ya lazima baada ya mpito kwenda ISO.

6. Maagizo ya Uhamishaji na Maagizo ya Ziada

• Taarifa za Malipo: Zisizopangiliwa (hadi herufi 140) au zilizopangiliwa (mf., maelezo ya ankara). Zinalingana na Field 70 katika MT 103 ya zamani; <RmtInf> katika pacs.008/pacs.009.
• Maelekezo kwa Mawakala: Kwa mfano, /REC/ kwa mpokeaji, /ACC/ kwa akaunti, au maelekezo ya simu (PHOB). Hulinganishwa na Field 72 katika MT ya awali; <InstrForNxtAgt>/<InstrForCdtrAgt> katika pacs.008/pacs.009.
• Viashiria vya Muda wa Malipo: Nyakati zilizoombwa (k.m., CLSTm kwa muda wa CLS).

Kwa nini inahitajika: Hutoa muktadha na maelekezo ya ushughulikiaji; ni muhimu kwa mbinu za cover katika pacs.009 COV.

7. Data za Udhibiti na Uzingatiaji wa Sheria na Kanuni

• Utoaji wa Taarifa kwa Wadhibiti: Misimbo au maelezo (k.m., kitambulisho cha kodi, kiashiria cha utoaji taarifa kama CRED/DEB). Huhusiana na Field 77B katika MT; <RgltryRptg> katika pacs.008/pacs.009.
• Misimbo ya Sababu za Kurejesha (inapohusika kwa marejesho): Kwa mfano, AC04 kwa akaunti iliyofungwa, katika pacs.004 iliyounganishwa na jumbe asilia.

Kwa nini inahitajika: Inatimiza wajibu wa AML/KYC na wa kuripoti; ni ya lazima katika njia za malipo zinazodhibitiwa.

Kwa mbinu bora, washiriki wasio wa gpi wanapaswa kupangilia data ili kuepuka kukatwa kwa taarifa wakati wa ubadilishaji wa MT kwenda MX na kushauriana na benki mwanachama wa gpi kuhusu mahitaji mahususi. Iwapo malipo yanahusisha mbinu za cover, taarifa za msingi za mteja lazima zifanane katika jumbe zote (kwa mfano, pacs.008 hadi pacs.009 COV).

Ujumbe wa Malipo katika SWIFT gpi

Katika mfumo wa SWIFT gpi (Global Payments Innovation), jumbe asili za malipo (k.m., pacs.008 kwa uhamishaji wa wateja au pacs.009 COV kwa uhamishaji wa dhamana ya malipo) huchukuliwa kuwa zisizobadilika baada ya kutumwa. Benki zinazopokea haziwezi kubadilisha moja kwa moja maudhui ya jumbe hizo, kwani jumbe za SWIFT zimeundwa kudumisha uadilifu na ukaguzi katika mnyororo mzima wa malipo. Badala yake, mabadiliko yoyote, marekebisho au ughairi hushughulikiwa kupitia jumbe tofauti za ufuatiliaji, masasisho ya hali kupitia gpi Tracker, au huduma maalumu kama gSRP (gpi Stop and Recall Payment). Hii inahakikisha ufuatiliaji wa mwanzo hadi mwisho kwa kutumia Kitambulisho cha Kipekee cha Muamala wa Mwanzo hadi Mwisho (UETR).

Hata hivyo, benki zinazopokea (kwa kawaida zikitenda kama wakala wa mdai au msuluhishi) zinaweza kujibu maombi ya mabadiliko kutoka kwa mtumaji au kuanzisha hatua ambazo kwa matokeo yake hurekebisha matokeo ya malipo (kwa mfano, urejeshaji au zuio). Pia zinaweza kuomba ufafanuzi au marekebisho kutoka kwa mtumaji chini ya masharti mahususi. Michakato hii inasimamiwa na vitabu vya kanuni vya SWIFT, miongozo ya mazoea ya soko (kwa mfano, kutoka Payments Market Practice Group – PMPG) na matakwa ya udhibiti, ikitanguliza uendeshaji wa kiotomatiki, uwazi na kuzuia udanganyifu.

Masharti kwa Benki Zinazopokea Kuomba au Kuwezesha Marekebisho
Benki zinazopokea zinaweza kuomba marekebisho (kwa mfano, masahihisho ya taarifa) au kuchukua hatua zinazodokeza hitaji la mabadiliko pale malipo ya awali hayawezi kushughulikiwa kama yalivyoagizwa. Hili kwa kawaida hufanywa kupitia ujumbe wa maulizo (kwa mfano, MT 195/199) au majibu kwa maombi yaliyoanzishwa na mtumaji. Masharti muhimu ni pamoja na:

• Makosa katika Taarifa za Malipo: Iwapo kuna kutokuwa sahihi kama vile akaunti isiyo sahihi ya mnufaika (mfano, akaunti iliyofungwa – msimbo AC04), sarafu isiyo sahihi (msimbo CURR), uelekezaji usio sahihi wa wakala (msimbo AGNT), au matatizo ya kiufundi (msimbo TECH), benki inayopokea inaweza kusimamisha malipo na kumwomba mtumaji atoe taarifa zilizosahihishwa au atume malipo mapya. Hii huepusha kukataliwa moja kwa moja huku ikiruhusu suluhisho.
• Kushindwa Kutumia Malipo: Chini ya msimbo CUTA (Cancel Upon Unable to Apply), ikiwa malipo hayawezi kuwekwa kwenye akaunti kutokana na kutolingana kwa taarifa (kwa mfano, tofauti ya jina/akaunti au maelezo yasiyotosheleza), benki mpokeaji inaweza kumwomba mtumaji maelezo ya kughairi au kurekebisha ili kurekebisha hali hiyo.
• Udanganyifu Unaoshukiwa au Miamala Isiyoidhinishwa: Kwa udanganyifu (msimbo FRAD), benki inayopokea inaweza kubaini matatizo kwa kujitegemea na kuanzisha kurejesha fedha bila ombi la awali kutoka kwa mtumaji. Pia inaweza kujibu maombi ya kurejesha ya mtumaji kwa kuzuia fedha na kuomba hati ya fidia (msimbo INDM) ikiwa fedha tayari zimewekwa kwenye akaunti, ili kupunguza hatari kabla ya kuzirejesha.
• Malipo Yaliyorudiwa au Yasiyostahili: Misimbo kama DUPL (malipo yaliyorudiwa) au UPAY (malipo yasiyostahili) huwezesha benki mpokeaji kuweka alama na kuomba kughairiwa iwapo muamala una kosa au hauna msingi.
• Masuala ya Udhibiti au Uzingatiaji wa Sheria na Kanuni: Ikiwa malipo yanakiuka sheria za mahali husika, vikwazo au mahitaji ya AML (msimbo LEGL), benki inayopokea inaweza kuyakataa au kuyazuia na kuomba nyaraka za ziada au marekebisho kutoka kwa mtumaji.
• Maamuzi ya Mteja au Mnufaika: Mnufaika akikataa malipo (msimbo CUST au NOAS – hakuna jibu kutoka kwa mnufaika), benki inayopokea inaweza kuyarejesha na kumjulisha mtumaji, huku ikiweza kuomba uthibitisho wa mabadiliko.
• Masuala Yanayosubiri Ufumbuzi: Kwa kesi zinazosubiri (msimbo PDCR), kama vile kusubiri idhini ya kutoza akaunti (RQDA) au jibu kutoka kwa wakala anayefuata (PTNA), benki inayopokea inaweza kuzuia malipo na kuomba maelekezo zaidi au marekebisho ili kuendelea.

Katika hali zote, maombi lazima yapangiliwe kwa ajili ya kiotomatiki (kwa mfano, kujumuisha UETR, marejeo ya awali kama sehemu ya 20/32A/50/59, na misimbo mahususi katika sehemu ya 79 ya ujumbe) ili kuwezesha uchakataji wa moja kwa moja (straight-through processing). Makubaliano ya fidia yanaweza kuhitajika baina ya pande mbili iwapo fedha zimewekwa kwenye akaunti, na benki inayopokea haina wajibu wa kukubali maombi lakini lazima ipe kipaumbele yale ya dharura (kwa mfano, yanayohusiana na ulaghai).

Michakato Inayohusika

• Majibu kwa Maombi ya Kurejesha Yanayoanzishwa na Mtumaji: Mtumaji (wakala wa mdaiwa) kwa kawaida huanzisha ombi la kurejesha kupitia MT 192/292 (au mfumo sawa wa ISO 20022 kama camt.056) kupitia huduma ya gSRP, linalotumwa kwa mfuatano au moja kwa moja kwa benki inayopokea. Benki inayopokea lazima ikubali mara moja na kujibu kwa MT 196/296 (au MT 199/299 ikiwa imepangiliwa), kwa kutumia misimbo kama CNCL (imeghairiwa), RJCR (imekataliwa kwa sababu iliyotajwa), au PDCR (inasubiri). Ikikubaliwa, fedha hurejeshwa kupitia pacs.004 (Urejeshaji wa Malipo).
• Hatua Huru za Benki Zinazopokea: Ikiwa ulaghai utagunduliwa ndani ya benki, benki inayopokea inaweza kurejesha fedha kwa kutumia pacs.004 pamoja na maelezo yaliyopangiliwa, na kutoa taarifa kupitia Tracker ili kupata hali ya wakati halisi.
• Maombi ya Marekebisho/Ufafanuzi: Benki zinazopokea hutumia ujumbe wa maulizo (kwa mfano, MT 195/295) kuomba mabadiliko, kama vile maelezo ya ziada. Hili ni jambo la kawaida kwa malipo yaliyositishwa.
• Ujumuishaji wa Kifuatiliaji: Hatua zote husasisha gpi Tracker kwa wakati halisi, na zinapatikana kupitia API au kiolesura cha picha (GUI), hivyo kuwezesha pande zote kuona hali ya muamala. Wanachama wa gpi lazima wazingatie vitabu vya kanuni vya lazima vya gCCT (Customer Credit Transfer), gCOV (Cover) na gSRP.
• Vikwazo na Mambo ya Mafanikio: Mabadiliko hayahakikishiwi; mafanikio hutegemea hatua ya malipo (rahisi zaidi kabla ya kuwekwa kwenye akaunti), ushirikiano wa mnufaika na mamlaka ya kisheria husika. Iwapo fedha zimeshawekwa kwenye akaunti, kurejesha kunahitaji idhini ya mnufaika au hati ya fidia. Kanuni na sheria daima hutangulia miongozo.

Taratibu hizi zinatumika hasa kwa wanachama wa gpi, lakini benki zisizo wanachama wa gpi zinaweza kushiriki kupitia lango maalum (gateways). Kwa maelezo ya hivi karibuni zaidi, tafadhali rejea vitabu rasmi vya kanuni vya SWIFT, kwani taratibu hubadilika (kwa mfano, kutokana na uhamiaji kwenda ISO 20022).

Utenganishaji wa Ujumbe na Ulipaji katika SWIFT gpi

SWIFT gpi hushughulikia hasa maagizo ya malipo na ufuatiliaji kupitia ujumbe (kwa mfano, miundo ya ISO 20022 kama pacs.008 kwa uhamisho wa wateja, pacs.009 kwa uhamisho wa kifedha, au MT 103/MT 202 za zamani), lakini uhamishaji halisi wa fedha hufanyika kando katika ngazi ya malipo ya mwisho (settlement). Malipo ya mwisho kwa kawaida hufanyika kupitia mahusiano ya benki mwakilishi (akaunti za nostro/vostro), ulinganishaji wa madeni ya pande mbili (bilateral netting), au Mifumo ya Kusafisha na Kukamilisha Malipo (Clearing and Settlement Mechanisms, CSMs) kama vile mifumo ya Malipo ya Papo Hapo kwa Kiasi Kamili (Real-Time Gross Settlement, RTGS) (kwa mfano, T2, iliyokuwa TARGET2 hapo awali, barani Ulaya, Fedwire nchini Marekani, au CHAPS nchini Uingereza). Gpi Tracker hutoa mwonekano wa papo hapo wa hali ya ujumbe, lakini uhamishaji wa fedha hutegemea mifumo hii ya msingi.

Kipindi cha kuishi pamoja kwa maagizo ya malipo ya kuvuka mipaka kilimalizika tarehe 22 Novemba 2025: maagizo ya malipo kama MT103 na MT202 yamechukuliwa na ujumbe wa ISO 20022 (MX) kama pacs.008 na pacs.009, huku kategoria nyingine za MT zikiondolewa kwa tarehe za baadaye. Yafuatayo yanaeleza jinsi marejesho na uachiliaji wa zuio hufanyika katika ngazi ya akaunti, ya kusafisha malipo na ya kukamilisha miamala.

Jinsi Fedha Zinavyorejeshwa Katika Ngazi ya Akaunti/Ulipaji wa Pamoja/Ukamilishaji wa Malipo
Urejeshaji huanzishwa baada ya ombi la kurejesha kufanikiwa (kupitia gSRP – huduma ya gpi Stop and Recall Payment) au baada ya kubainika kwa kujitegemea (kwa mfano, ulaghai, makosa). gSRP hutumia camt.056 (Ombi la Kufuta Malipo) kutoka kwa mtumaji, ambalo hujibiwa kwa camt.029 (Hitimisho la Uchunguzi). Ombi likikubaliwa, urejeshaji wa fedha hutekelezwa kupitia agizo jipya la malipo linalogeuza mtiririko, kwa kutoa fedha kwenye akaunti ya benki inayopokea na kuzirudisha kupitia mnyororo. Huu si mabadiliko ya ujumbe wa awali bali ni muamala tofauti.

Njia Kuu za Malipo ya Mwisho na Michakato ya Marejesho
Njia za malipo ya mwisho huamua jinsi marejesho yanavyofanyika:

• CLRG (Ulipaji kupitia Miundombinu ya Soko): Usuluhishi kupitia RTGS au CSM (kwa mfano, kupitia benki kuu). Marejesho hutumia pacs.004 kuelekeza miundombinu ya soko kutoa kiasi kwenye akaunti ya wakala anayepokea na kuweka kwenye akaunti ya wakala wa awali, mara nyingi kwa wakati halisi au siku hiyo hiyo.
• INGA (Wakala Anayeelekeza Hulipa Kwanza): Mtumaji hulipa fedha kabla ya kutuma ujumbe. Marejesho kupitia pacs.004 hutoa fedha kwenye akaunti ya wakala aliyeelekezwa baada ya malipo.
• INDA (Wakala Aliyeagizwa Hutatua Baada ya Kupokea): Mpokeaji hutatua mara tu anapopokea ujumbe. Ikiwa haijatatuliwa, hukataliwa kupitia pacs.002 (hakuna fedha zinazohamishwa); ikiwa imetatuliwa, hurejeshwa kupitia pacs.004.
• COVE (Njia ya Cover): Hutumika kwa malipo ya thamani ya juu yanayohusisha uhamisho wa cover (pacs.009 COV). Marejesho hufuata mnyororo wa kinyume: pacs.004 kutoka kwa wakala wa mnufaika kurudi kwa wasuluhishi, huku akaunti za benki wakala zikidaiwa/kukopeshwa ipasavyo.

Hatua kwa Hatua za Mchakato wa Kurejesha Fedha katika Ngazi ya Ukamilishaji wa Miamala

1. Kuanzisha na Kukubali: Mtumaji huomba kurejeshwa kwa malipo (kwa mfano, kupitia camt.056 yenye UETR). Mpokeaji hujibu (camt.029) na hukubali iwapo fedha zinapatikana na bado hazijawekwa kwa mnufaika (ni rahisi kabla ya kuwekwa). Iwapo fedha zimeshawekwa, idhini ya mnufaika au hati ya fidia inaweza kuhitajika.

2. Maelekezo ya Kurejesha Fedha: Mpokeaji hutoa pacs.004 (Payment Return) au MT 103/MT 202 za zamani zikiwa na misimbo ya kurejesha (kwa mfano, RETN). Ujumbe huu unajumuisha:

• Marejeleo asilia (UETR, End-to-End ID, Instruction ID).
• Majukumu hubadilishwa: Mdai wa awali anakuwa mdaiwa; wakala wa mdaiwa wa awali anakuwa mdai.
• Maelezo ya ulipaji: Kiasi/Tarehe Asilia ya Ulipaji kati ya Benki, Kiwango cha Ubadilishaji (iwapo fedha za kigeni zinahusika), Ada (iwapo zimekatwa).
• Msimbo wa Sababu ya Kurejesha (k.m., AC04 kwa akaunti iliyofungwa, FRAD kwa ulaghai).
• Sehemu ya Akaunti ya Ulipaji (iwapo ipo kwenye ujumbe wa awali) ya kubainisha akaunti itakayowekewa fedha.

3. Utekelezaji wa Malipo ya Makubaliano:

• Ujumbe wa pacs.004 husababisha kutozwa (debit) kwenye akaunti ya nostro/vostro ya benki inayopokea (inayoshikiliwa kwa wakala wa awali au MI).
• Fedha hurejeshwa kwa mkopo hatua kwa hatua kupitia mnyororo, kwa kutumia njia ile ile ya malipo ya mwisho (mfano, uhamisho wa RTGS katika CLRG).
• Iwapo ni urejeshaji wa sehemu, taja “PART” katika Taarifa za Ziada pamoja na kiasi kilichokokotolewa kwa uwiano.
• Kifuatiliaji husasisha hali (kwa mfano, “Imerejeshwa”) papo hapo, na hali hiyo huonekana kupitia API au GUI.

4. Ulipaji wa Mwisho: Akaunti ya mtumaji wa awali huwekewa fedha, mara nyingi baada ya makato ya ada. Ikiwa ni kupitia CSM, usuluhishaji hufanyika kwa pamoja na kwa wakati mmoja (atomic); katika mipangilio ya pande mbili, unaweza kuhusisha kulinganisha na kupunguza madai ya mwisho wa siku (netting).

5. Arifa za Baada ya Kurejesha: Tumia camt.053/054 (Taarifa ya Akaunti/Arifa ya Debiti-Krediti) kuthibitisha masasisho ya leja. Hakuna pacs.004 nyingine ya "kurejesha urejeshaji": tumia maulizo badala yake.
Urejeshaji hufanywa kiotomatiki inapowezekana, lakini uingiliaji wa mikono unaweza kutokea kwa sababu za uzingatiaji wa sheria au iwapo fedha zimezuiwa. Urejeshaji hauhakikishiwi; unategemea zaidi jinsi ombi la kurejesha lilivyotumwa haraka na kama fedha tayari zimewekwa kwenye akaunti. Ikiwa malipo hayajakamilishwa (kwa mfano, yamekataliwa kabla ya kukamilishwa), hakuna fedha zinazohamishwa: tumia pacs.002 badala yake.

Jinsi Malipo Yaliyozuiliwa Yanavyoachiliwa (Kupewa Ruhusa ya Kuendelea) katika Ngazi ya Akaunti/Ubadilishanaji/Ukamilishaji

Kuzuiliwa hutokea pale malipo yasipoweza kushughulikiwa mara moja (kwa mfano, kutokana na makosa, ukaguzi wa uzingatiaji wa sheria na kanuni, au kusubiri ufafanuzi), na kuyaweka katika hali ya “inasubiri” bila kusuluhishwa. Hakuna fedha zinazokatwa wala kuwekwa hadi suala litakapotatuliwa. gpi Tracker huonyesha hali kama “On Hold” au “Pending” (kwa mfano, msimbo wa PDCR), na utatuzi hutumia ujumbe wa maulizo (MT 195/199 au camt.029).

Hali Zinazosababisha Zuio

• Kutolingana (mf., tofauti kati ya akaunti na jina – msimbo wa CUTA).
• Ukaguzi wa udhibiti (k.m., vikwazo – msimbo wa LEGL).
• Inasubiri jibu la mnufaika (msimbo wa NOAS) au idhini ya kutoza akaunti (RQDA).
• Saa za kutofanya kazi mtandaoni au usindikaji wa kundi la miamala katika benki ya mnufaika.

Mchakato wa Kuachilia katika Ngazi ya Malipo
1. Taarifa ya Kuzuia: Mpokeaji hutuma pacs.002 (taarifa ya hali) au MT 199 yenye msimbo wa kusubiri, akishikilia fedha katika akaunti ya muda/escrow iwapo malipo yamekamilika kwa sehemu (kwa mfano, katika njia za cover).
2. Utatuzi: Mtumaji hutoa marekebisho/ufafanuzi (kwa mfano, kupitia jibu la MT 195 au camt.029). Ikiwa suala limetatuliwa, mpokeaji huidhinisha kwa kuchakata maelekezo ya awali.
3. Utekelezaji wa Malipo:

• pacs.008/pacs.009 ya awali inaachiliwa kutoka kwenye kushikiliwa.
• Fedha hukamilishwa kwa njia iliyobainishwa: akaunti ya mtumaji hutozwa, akaunti ya mpokeaji hukopeshwa (kwa mfano, kupitia RTGS katika CLRG), kisha mikopo ya mwisho huwekwa kwenye akaunti ya mnufaika.
• Hatua ya mnufaika (kutoka benki mpokeaji hadi mteja wa mwisho) mara nyingi ndiyo huchelewesha malipo, hasa katika masoko yenye udhibiti wa mitaji au miundombinu midogo.
• Kifuatiliaji husasishwa kuwa “Credited” au “Completed,” huku pacs.002 (Payment Status Report) ikithibitisha.

4. Ikiwa Haijaachiliwa: Ikiwa haijatatuliwa (kwa mfano, baada ya muda kuisha), rudisha kupitia pacs.004 kama ilivyoelezwa hapo juu, au kataa kwa pacs.002 (hakuna ulipaji).

Kanuni za gpi zinahitaji fedha ziwekwe kwenye akaunti siku hiyo hiyo inapowezekana; Swift iliripoti mwaka 2018 kwamba karibu 50% ya malipo ya gpi yaliwekwa kwenye akaunti ndani ya dakika 30 na karibu 100% ndani ya saa 24. Mambo kama vizuizi vya mitaji au saa ambazo benki haipo mtandaoni yanaweza kurefusha kushikiliwa kwa fedha, lakini gpi inasisitiza uendeshaji wa kiotomatiki ili kupunguza hali hiyo.

SwiftNet Instant

SwiftNet Instant. Ni jukwaa la ujumbe la wakati halisi lenye ucheleweshaji mdogo sana, linalopatikana saa 24 kila siku, na linaloruhusu ubadilishanaji salama wa mtiririko wa malipo ya papo hapo kati ya Mifumo ya Kusafisha na Kusuluhisha (Clearing and Settlement Mechanisms, CSMs) na washiriki wake.

Wateja wanaweza kuunganishwa na SwiftNet Instant kupitia miundombinu yao iliyopo ya muunganisho na usalama ya Swift, ikijumuisha visanduku vya VPN, laini za kukodi na moduli za usalama wa vifaa (hardware security modules). Uunganishaji na mazingira ya TEHAMA ya benki hufanikishwa kupitia Alliance Gateway Instant (AGI).

Pande zote katika mnyororo wa malipo ya papo hapo zinaweza kutumia ujumbe wa AGI na SwiftNet Instant. Matumizi yake ni pamoja na kuanzisha malipo kutoka huduma ya juu (overlay), mawasiliano yasiyo ya moja kwa moja na mwanachama mdhamini, au shirika kupokea uthibitisho wa malipo.

SWIFT Instant huunganishwa na mifumo ya ndani ya malipo ya papo hapo ili kuwezesha uchakataji wa miamala kwa wakati halisi, ndani ya nchi na kimataifa, kwa kutumia kiwango cha ISO 20022. Mifumo hii ni sehemu ya juhudi zinazoendelea za kuboresha na kurahisisha michakato ya malipo katika sekta ya fedha.

Makato ya Moja kwa Moja kupitia SWIFT

Makato ya moja kwa moja (direct debit) katika mfumo wa SWIFT ni njia ya malipo inayowawezesha wafanyabiashara na watu binafsi kukusanya fedha kutoka akaunti za benki za wadaiwa kwa sarafu mbalimbali na katika nchi tofauti. Tofauti na SEPA Direct Debit, iliyoundwa mahsusi kwa ukanda wa SEPA na inayoishia kwenye miamala ya sarafu ya euro, makato ya moja kwa moja katika SWIFT yana wigo wa kimataifa na yanasaidia aina mbalimbali za sarafu.

Mchakato wa kuanzisha muamala wa makato ya moja kwa moja (direct debit) ndani ya mfumo wa SWIFT kwa kawaida unahusisha hatua zifuatazo:

1. Makubaliano kati ya mdai na mdaiwa: Mdai na mdaiwa lazima wawe na makubaliano yaliyopo awali, yanayojumuisha masharti na vigezo vya miamala ya malipo ya moja kwa moja kutoka akaunti (direct debit). Makubaliano haya yanaweza pia kuhusisha uwekaji wa idhini au ruhusa, inayomwezesha mdai kukusanya malipo kutoka akaunti ya benki ya mdaiwa.
2. Ubadilishanaji wa ujumbe: Benki ya mdai huanzisha makato ya moja kwa moja kwa kutuma ujumbe wa SWIFT kwa benki ya mdaiwa – katika ISO 20022 ni pacs.003 (makato ya moja kwa moja ya mteja) au pacs.010 (makato ya moja kwa moja ya taasisi ya kifedha), ambazo hapo awali zilikuwa MT 104 au MT 204. Ujumbe huu una maelezo ya muamala, kama vile kiasi, sarafu, taarifa za akaunti ya mdaiwa, na taarifa nyingine zozote zinazohitajika.
3. Uhakiki na idhini: Benki ya mdaiwa huthibitisha maelezo ya muamala, hukagua upatikanaji wa fedha katika akaunti ya mdaiwa, na kuthibitisha idhini ya muamala huo. Ikiwa kila kitu kiko sawa, benki ya mdaiwa huendelea kutoa fedha hizo kutoka akaunti ya mdaiwa.
4. Uhamisho wa fedha: Fedha hukamilishwa kati ya benki ya mdaiwa na benki ya mdai kupitia akaunti za benki mwakilishi au mfumo wa kusafisha na kukamilisha malipo.
5. Uthibitisho: Baada ya kupokea fedha, benki ya mdai humtumia mdai ujumbe wa uthibitisho, ikimjulisha kuwa muamala wa makato ya moja kwa moja umefanikiwa.

Masharti ya awali ya kuanzisha muamala wa malipo ya moja kwa moja kutoka akaunti (direct debit) ndani ya mfumo wa SWIFT ni kama ifuatavyo:

1. Akaunti za benki: Mdai na mdaiwa wote wanapaswa kuwa na akaunti za benki katika taasisi za kifedha zilizo sehemu ya mtandao wa SWIFT.
2. Makubaliano na idhini: Makubaliano na idhini (agizo) vilivyokuwepo awali kati ya mdai na mdaiwa lazima viwepo ili kuwezesha miamala ya makato ya moja kwa moja.
3. Miundo ya ujumbe wa SWIFT: Mdai wa deni na benki yake lazima watumie miundo ifaayo ya ujumbe: pain.008 kuanzisha makato ya moja kwa moja ya akaunti (direct debit), pacs.003 au pacs.010 kati ya benki.
4. Ada za benki: Mdai na mdaiwa wanapaswa kufahamu ada zozote zinazohusiana na miamala ya malipo ya moja kwa moja (direct debit) ndani ya mfumo wa SWIFT, kwani ada hizi zinaweza kutofautiana kulingana na benki na nchi zinazohusika.

RMA katika Ujumbe wa SWIFT Kati ya Benki

Katika huduma za kibenki na fedha, mawasiliano salama na yenye ufanisi kati ya benki ni muhimu. Hapa ndipo SWIFT (Society for Worldwide Interbank Financial Telecommunication) inapotekeleza jukumu muhimu, ikibeba sehemu kubwa ya jumbe za kimataifa kati ya benki. Sehemu muhimu inayohakikisha usalama na uteuzi wa mawasiliano haya ni Relationship Management Application (RMA).

RMA ni nini?

Relationship Management Application (RMA) ni programu ya SWIFT inayoruhusu taasisi za kifedha kubainisha ni wenza gani wanaoweza kuzitumia ujumbe wa SWIFT, na kuhakikisha kwamba mawasiliano ya mtandao wa SWIFT yamewekewa mipaka kwa watumiaji waliothibitishwa pekee. RMA ni safu ya msingi ya usalama katika usimamizi wa mawasiliano kati ya benki, kwani huchuja ujumbe usioidhinishwa na kupunguza hatari ya udanganyifu.

Umuhimu wa RMA

Kwa benki zinazojihusisha na ufadhili wa kimataifa, kama vile IFB, chombo cha RMA ni muhimu sana. Hakiimarishi tu itifaki za usalama bali pia kinahakikisha uzingatiaji wa kanuni za kibenki za kimataifa. Kwa kusimamia ni taasisi zipi zinaweza kuwatumia jumbe, benki zinaweza kuzuia maombi ya taarifa na maagizo ya kifedha yasiyoidhinishwa, na hivyo kulinda maslahi yao na ya wateja wao.

Jinsi RMA Inavyofanya Kazi

Mchakato wa RMA unahusisha hatua kuu zifuatazo:

1. Kuanzisha Mahusiano ya RMA: Kabla ya benki mbili kuanza kubadilishana taarifa kupitia SWIFT, lazima zikubaliane kwa pamoja kuanzisha RMA. Makubaliano haya ni sawa na kupeana mkono kidijitali, yakiashiria kuaminiana na ridhaa ya kuwasiliana.
2. Kubadilishana Funguo: Kila benki hutuma idhini ya RMA kupitia programu ya RMA, ambayo benki nyingine huikubali. RMA ilichukua nafasi ya ubadilishanaji wa awali wa funguo baina ya benki mbili (BKE); ujumbe wenyewe huthibitishwa kupitia SWIFTNet PKI (Miundombinu ya Funguo za Umma).
3. Kusanidi Mipangilio ya RMA: Kila benki hutumia zana ya RMA kusanidi ruhusa na kubainisha aina za ujumbe unaokubaliwa kutoka kwa benki nyingine. Hii inaweza kuwekwa kwa upana au kurekebishwa kwa umakini ili kujumuisha aina mahususi za ujumbe na makundi madogo.
4. Uwezeshaji na Ufuatiliaji: Mara baada ya mipangilio ya RMA kusanidiwa na kuwezeshwa, benki zinaweza kufuatilia jumbe zinazoingia ili kuhakikisha zinazingatia ruhusa zilizowekwa. RMA pia hutoa zana za kurekebisha au kufuta ruhusa iwapo mahitaji ya kibiashara au masuala ya usalama yatahitaji hivyo.

Matumizi ya Vitendo

Kwa IFB, ambayo inajishughulisha na uwekezaji na usimamizi wa utajiri kwa watu binafsi wenye utajiri mkubwa na mashirika ya kibiashara, RMA hutoa manufaa kadhaa:

• Usalama Ulioimarishwa: Kwa kudhibiti mtiririko wa ujumbe, IFB inaweza kulinda miamala ya wateja na taarifa nyeti dhidi ya ufikiaji usioidhinishwa.
• Ufanisi wa Kiutendaji: Mawasiliano yaliyorahisishwa na taasisi zinazoaminika huwezesha usindikaji wa haraka wa jumbe halali, na hivyo kuboresha nyakati za kujibu na kuridhika kwa wateja.
• Uzingatiaji wa Kanuni: RMA husaidia kuzingatia kanuni za kimataifa za kibenki, zinazohitaji udhibiti mkali wa ubadilishanaji wa taarifa ili kuzuia uhalifu wa kifedha kama vile utakatishaji wa fedha na ulaghai.

RMA na MT799. Benki zinaweza kutumia MT799 kuomba au kuratibu uhusiano wa RMA, mradi njia ya mawasiliano inaruhusu hilo. Idhini ya RMA yenyewe hutolewa katika mfumo wa RMA; MT799 pekee haiwezeshi ruhusa yoyote. Pale ambapo idhini ya RMA inayohitajika kwa MT799 haipo, haiwezi kukwepwa kwa kutuma MT799 moja kwa moja. Mpangilio huo basi hukubaliwa kupitia kipengele cha mawasiliano ya RMA cha Relationship Management Portal ya Swift, kilichobuniwa kwa ajili ya uratibu na pande husika kabla ya kubadilishana idhini, au kupitia njia nyingine iliyoruhusiwa. Kwa hiyo, “RMA kwa MT799” inaweza kuelezea mawasiliano ya kibenki yanayoambatana; idhini ya kiufundi ya RMA ni hatua tofauti.

Kwa ufupi

Kwa IFB, utekelezaji madhubuti wa RMA si hitaji la kiufundi tu bali ni rasilimali ya kimkakati katika shughuli zake za kimataifa. Unaimarisha dhamira ya benki kuhusu usalama na uzingatiaji wa sheria na kanuni, huku ukiongeza ufanisi wa mitandao yake ya mawasiliano. Mazingira ya fedha za kimataifa yanapoendelea kubadilika, zana kama RMA zinaendelea kuwa muhimu kwa benki zilizojitolea kudumisha viwango vya juu kabisa vya uadilifu wa kiutendaji na huduma kwa wateja.

RMA ndizo msingi wa mawasiliano salama na teule kati ya benki, zikihakikisha kwamba kila ujumbe unaobadilishwa kupitia mtandao wa SWIFT unazingatia viwango vya juu kabisa vya usalama na unathibitishwa kikamilifu. Kwa benki kama IFB, kuelewa na kusimamia RMA ni jambo muhimu katika kulinda shughuli zake na kujenga imani na washirika wake wa kimataifa.

Maelekezo ya Kifedha ya Swift ya Kidijitali kwa Teknolojia ya Blockchain

Mwezi Septemba 2025 Swift ilitangaza kwamba, kwa kushirikiana na taasisi zaidi ya 30 za kifedha, ilikuwa imeanza kubuni na kuendeleza leja ya kidijitali ya pamoja. Tarehe 9 Julai 2026 Swift ilitangaza kwamba leja hiyo ilikuwa tayari kwa matumizi ya awali, huku benki 17 zikijiandaa kufanya majaribio ya miamala halisi ya amana zilizotokenishwa: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB na Wells Fargo. Matumizi ya kwanza yatalenga kuwezesha maagizo ya papo hapo, saa 24 kwa siku, siku 7 kwa wiki, ya kuvuka mipaka kati ya benki – uboreshaji muhimu katika mfumo wa usindikaji wa miamala ya kimataifa.

Mfano wa kwanza wa dhana ulijengwa kwa ushirikiano na Consensys. Leja imebuniwa kuwa rejista salama, isiyobadilika na ya wakati halisi ya maagizo ya kifedha kati ya taasisi. Itarekodi, kupanga mfuatano na kuthibitisha ujumbe wa miamala, huku ikitekeleza kanuni za uendeshaji na uzingatiaji wa sheria kupitia mikataba janja. Ushirikiano wa kimfumo ni kanuni kuu: leja itaunganishwa na miundombinu iliyopo na inayoibuka, huku ikidumisha sifa mahususi za Swift za uthabiti, uaminifu na uzingatiaji wa kanuni za udhibiti.

Kama Mkurugenzi Mtendaji wa Swift, Javier Pérez-Tasso, alivyoeleza:
“Kuunganisha leja ya pamoja na ujumbe uliopo wa Swift, API na ISO 20022 kunaunda mfumo wenye nguvu zaidi – unaoweza kujumuisha hatari, udhibiti na mahitaji ya uzingatiaji wa sheria tangu mwanzo katika mtiririko wa miamala, huku ukiwezesha maelekezo ya kimataifa kati ya benki kwa wakati halisi saa 24 siku 7 kwa uaminifu, usalama, ustahimilivu, upanukaji na ubora wa uendeshaji ule ule ambao Swift inajulikana kwao. Yote yakiwa sambamba na mtazamo tuliouchukua daima wa uvumbuzi wenye uwajibikaji.”

Upanuzi wa Miundombinu

Leja ya pamoja inakamilisha mifumo iliyopo ya Swift; haiibadilishi. Imeundwa kupanua uratibu na uwezo wa mifumo kuwasiliana, ili kuhakikisha kuwa taasisi za kifedha zinaweza kubadilishana maagizo kwa kasi zaidi, kwa utabirikaji mkubwa zaidi, na kwa kiwango cha kimataifa kweli.

Katika Sibos, Pérez-Tasso alisisitiza mkabala huu wa njia mbili:
“Miundombinu ya kifedha inapaswa kuendelea kuzingatia kwa dhati misingi ya ubora wa utendaji, uzingatiaji wa sheria na kanuni, na utawala. Na wakati huo huo, inapaswa kujiandaa kwa siku zijazo. Na katika Swift, mkabala wetu ni kuvumbua kupitia njia mbili sambamba.”

Ushirikiano katika Sekta Nzima

Taasisi za kifedha kutoka nchi 16 zilishirikishwa tangu mwanzo katika kuunda muundo, usimamizi, na mwelekeo wa maendeleo wa leja ya pamoja. Juhudi hii ya pamoja inasisitiza utambuzi wa pamoja: kuendeleza miundombinu ya kimataifa ya maagizo kati ya benki kunahitaji ukubwa na ushirikiano.

Mtazamo wa Mbeleni

Leja ya pamoja ni hatua ya asili inayofuata majaribio ya awali ya Swift ya mali za kidijitali na ni sehemu ya dhamira pana ya kuwezesha ushirikiano kati ya mitandao ya umma na ya kibinafsi. Hii itaruhusu thamani ya kidijitali iliyodhibitiwa na hati za kawaida za kifedha kuhama kwa urahisi kati ya mifumo mbalimbali.

Pérez-Tasso alifupisha maono hayo:
“Hili ni jukwaa lenye nguvu kwa siku zijazo. Na linaweza kuleta mabadiliko makubwa zaidi siku zijazo.”

Maswali Yanayoulizwa Mara kwa Mara

Leja ya pamoja ya Swift inayotegemea blockchain ni nini?
Ni miundombinu ya blockchain inayotoa rekodi ya pamoja ya wakati halisi ya maagizo ya kifedha kati ya taasisi, ikiwezesha uchakataji endelevu na unaozingatia sheria na kanuni katika mipaka ya nchi.

Ni kwa ajili ya nani?
Benki na taasisi za kifedha zinazopaswa kutoa maagizo ya miamala kwa kasi zaidi na uwazi zaidi huku zikijiandaa kwa mustakabali wa kidijitali.

Faida zake ni zipi?

• Uonekanaji wa papo hapo na mpangilio wa maagizo
• Uzingatiaji wa sheria na kanuni wa kiotomatiki kupitia mikataba janja
• Ushirikiano wa kiutendaji kati ya mitandao ya jadi na ya kidijitali
• Ushughulikiaji salama wa mtiririko wa thamani ya kidijitali (tokeni) uliodhibitiwa

Inaendana vipi na jukwaa la Swift?
Inapanua miundombinu inayoaminika ya Swift, ikijumuisha uwezo wa maagizo ya kidijitali huku ikidumisha ustahimilivu, usalama na uzingatiaji wa sheria na kanuni.

Matumizi ya kwanza ni yapi?
Maelekezo ya miamala baina ya benki kuvuka mipaka kwa wakati halisi, saa 24 kwa siku, siku 7 kwa wiki.

Nani anahusika?
Taasisi zaidi ya 30 za kifedha kutoka nchi 16 zilichangia katika kuunda muundo huu; benki 17 zinafanya majaribio ya miamala ya kwanza ya moja kwa moja.

Utapatikana lini?
Swift ilitangaza leja kuwa tayari kwa matumizi ya awali tarehe 9 Julai 2026. Benki za majaribio zinaendesha miamala ya awali ya moja kwa moja katika awamu ya kuanza kwa udhibiti; ulipaji wa mwisho bado unapitia mifumo iliyopo. Utendaji kazi na upatikanaji vitapanuliwa baadaye.

Ikiwa unataka kujua zaidi kuhusu jinsi ya kuhamisha fedha kupitia mfumo wa benki mwakilishi, tafadhali wasiliana na Mkuu wetu wa Huduma za Benki Mwakilishi, Bw. Amri Elarisse