Day 14 – Digital Wallet တွေ ငွေဖြည့်တာ၊ ငွေထုတ်တာ

ငွေဖြည့်ခြင်း (Adding money)
- Digital wallet တွေကို ငွေဖြည့်တဲ့အခါ နည်းလမ်း ၃-မျိုးနဲ့ ငွေဖြည့်လို့ရပါတယ်။ ပထမဆုံးနည်းလမ်းက နီးစပ်ရာ wallet agent သို့မဟုတ် အခြားသူတစ်ယောက်ရဲ့ wallet balance ကနေ ငွေထည့်ပေးတာ ဖြစ်ပါတယ်။ နောက်တစ်နည်းက wallet ထဲကို ခွင့်ပြုထားတဲ့ ဘဏ်အကောင့်ကနေ ငွေလွှဲပြီး ထည့်တာဖြစ်ပါတယ်။ နောက်တစ်နည်းက debit ကတ်၊ credit ကတ် အစရှိတဲ့ ကတ်တွေကနေ top-up လုပ်ပြီး ငွေထည့်တာ ဖြစ်ပါတယ်။

ငွေထုတ်ခြင်း (Withdrawing money)
- Wallet တွေကနေ ငွေထုတ်ဖို့မှာလည်း နည်းလမ်း ၃-မျိုးနဲ့ ထုတ်လို့ရပါတယ်။ ပထမဆုံးနည်းလမ်းက နီးစပ်ရာ wallet agent ကနေ ငွေထုတ်တာပါ။ ‌နောက်တစ်နည်းက အဲ့ဒီ wallet နဲ့ ချိတ်ဆက်ထားတဲ့ ဘဏ်ရဲ့ ATM မှာ ငွေထုတ်တာပါ။ ‌နောက်တစ်နည်းကတော့ wallet နဲ့ ချိတ်ဆက်ထားတဲ့ ဘဏ်အကောင့်ထဲကို ငွေလွှဲထည့်တာပါ။ Wallet agent ဆီမှာ ငွေထုတ်တာနဲ့ ATM မှာ ငွေထုတ်တာတွေမှာ ငွေသားထုတ်ယူနိုင်မှာပေမယ့်၊ ဘဏ်အကောင့်ထဲကို ငွေလွှဲထည့်မယ်ဆိုရင်တော့ digital money အနေနဲ့ပဲရမှာပါ။ ဒါပေမယ့် ဘဏ်အကောင့်ထဲကို ငွေရောက်သွားတာဖြစ်တဲ့အတွက် ဘဏ်မှာ ငွေသွားထုတ်လို့ရသလို အဲ့ဒီ ဘဏ်အကောင့်နဲ့ ချိတ်ဆက်ထားတဲ့ ATM တွေမှာလည်း debit ကတ်နဲ့ ငွေသားအလွယ်တကူ ထုတ်ယူလို့ရပါတယ်။

“Payments Made Simple” 40 day series - day 14 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 15 - Digital Payment ရဲ့ Tokenization ဆိုတာ...

Tokenization ဆိုတာ ပေါက်ကြားလို့မရတဲ့ sensitive ဖြစ်တဲ့ ကတ်၊ wallet နဲ့ ဘဏ်အကောင့်စတဲ့ အချက်အလက်တွေကို လုံခြုံပြီး unique ဖြစ်တဲ့ token နဲ့ အစားထိုး သုံးစွဲတာ ဖြစ်ပါတယ်။ Token ကို အသုံးပြုပြီး ငွေပေးချေတဲ့အခါမှာ ကတ်အချက်အလက်၊ wallet အချက်အလက် အစရှိတာတွေကို တိုက်ရိုက် သိမ်းဆည်ထိတွေ့စရာ မလိုအပ်တော့ပါဘူး။ တစ်ချိန်ချိန်မှာ token အခိုးခံရတာ၊ ပေါက်ကြားတာ ဖြစ်လာခဲ့ရင်လည်း token data တွေဟာ ကတ်၊ wallet တွေရဲ့ အချက်အလက်အစစ်တွေ မဟုတ်တာမို့ ခိုးယူသူလက်ထဲမှာ အသုံးမဝင်ပါဘူး။

Tokenization အလုပ်လုပ်ပုံကတော့ တကယ့် ကတ်၊ wallet နံပါတ်တွေ၊ အချက်အလက်တွေကို issuer သို့မဟုတ် provider ဆီမှာပဲ လုံခြုံစွာ သိမ်းဆည်းထားပါတယ်။ အသုံးပြုမယ့် device ၊ app နဲ့ merchant တစ်ခုချင်းစီအတွက် သီးသန့် token တစ်ခုစီ ထုတ်ပေးထားပါတယ်။ ငွေပေးချေတဲ့အချိန်မှာ အဲ့ဒီ token ကိုပဲ အသုံးပြုပြီး transaction ပြုလုပ်မှာဖြစ်ပြီး အချက်အလက် အစစ်တွေကို အသုံးမပြုပါဘူး။ Issuer နဲ့ provider တွေဆီ transaction ရောက်သွားတဲ့အခါကျမှ အဲ့ဒီ token နဲ့ ချိတ်ဆက်ထားတဲ့ ကတ်၊ အကောင့်အချက်အလက်တွေကို provider ကနေ သိရှိပြီး transaction ကို အတည်ပြုပေးမှာ ဖြစ်ပါတယ်။

Tokenization ကို အသုံးပြုတာကြောင့် user တွေရဲ့ အချက်အလက် credential တွေ ပေါက်ကြားနိုင်ခြေကို လျှော့ချပေးပါတယ်။ ခိုးယူသုံးစွဲခံရနိုင်ခြေ fraud risk လည်း နည်းသွားပါတယ်။ အွန်လိုင်း၊ မိုဘိုင်း app တွေနဲ့ wallet တွေမှာ ငွေပေးချေမှုတွေကို လုံခြုံစိတ်ချ ရစေပါတယ်။ Stored payment method တွေကို အသုံးပြုပြီး user တွေရဲ့ ကတ်၊ wallet အကောင့်အချက်အလက် စတာတွေကို merchant တွေ၊ app တွေဆီမှာ အချက်အလက် အစစ်တွေကို ထိတွေ့စရာမလိုဘဲ လုံခြုံစိတ်ချစွာ သိမ်းဆည်းနိုင် ပေးချေနိုင်စေပါတယ်။

“Payments Made Simple” 40 day series - day 15 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 16 – ငွေပေးချေရာမှာ အကောင့်ပိုင်ရှင်ကို အတည်ပြုဖို့ အသုံးပြုတဲ့ နည်းလမ်းများ

ကတ်၊ wallet ၊ internet banking ၊ mobile banking အစရှိသဖြင့် digital payments တွေနဲ့ ငွေပေးချေတဲ့အခါ အသုံးပြုသူတွေကို ကတ်၊ အကောင့်ပိုင်ရှင် စစ်မှန်ကြောင်း အတည်ပြုနိုင်ဖို့ စစ်ဆေးတဲ့ အဆင့်တွေ ရှိတတ်ပါတယ်။ အသုံးများတဲ့ နည်းလမ်းတွေကတော့ –

(၁) OTP (One-Time Password) – တစ်ခါသုံးလျှို့ဝှက်နံပါတ်ဖြစ်ပြီး SMS ၊ email နဲ့ app တွေကနေ ပို့ပေးပါတယ်။ ကုဒ်နံပါတ်ကို မှန်ကန်စွာ ရိုက်ထည့်ပြီး အတည်ပြုပေးရပါမယ်။

(၂) PIN (Personal Identification Number) – ကတ်၊ wallet နဲ့ digital payment တွေနဲ့ ငွေပေးချေတဲ့အခါ ရိုက်ထည့်နိုင်ဖို့ ကြိုတင်သတ်မှတ်ထားတဲ့ လျှို့ဝှက်ကုဒ် ဖြစ်ပါတယ်။ ကုဒ်နံပါတ်ကို မှန်ကန်စွာ ရိုက်ထည့်ပြီး အတည်ပြုပေးရပါမယ်။

(၃) Biometrics – Fingerprint ၊ face recognition အစရှိသဖြင့် အသုံးပြုတဲ့စက်၊ ဖုန်းကို အသုံးပြုပြီး ဇီဝအချက်အလက်နဲ့ စစ်ဆေးတာ ဖြစ်ပါတယ်။

(၄) App-based approval – ငွေပေးချေသူရဲ့ app ဆီကို push notification ပို့ပေးပြီး ငွေပေးချေမှုကို အတည်ပြုခိုင်းတာ ဖြစ်ပါတယ်။

ဒီနည်းလမ်းတွေနဲ့ လိမ်လည်မှု fraud ဖြစ်နိုင်ခြေ၊ ကတ်၊ အကောင့်တွေ ခိုးယူသုံးစွဲခံရနိုင်ခြေ အစရှိတဲ့ အန္တရာယ်တွေကနေ လျှော့ချပေးပါတယ်။ ငွေပေးချေမှုတိုင်းမှာတော့ အဲ့ဒီလို စစ်ဆေးမှာ မဟုတ်ပါဘူး။ ငွေပမာဏ များတာ၊ သံသယဖြစ်စရာ risk ရှိတာနဲ့ transaction အမျိုးအစားအပေါ် မူတည်ပြီး လိုအပ်တဲ့ အခြေအနေတွေအတွက်ပဲ စစ်ဆေးမှာ ဖြစ်ပါတယ်။

“Payments Made Simple” 40 day series – day 16 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 17 - Merchant များ ဖြစ်လေ့ဖြစ်ထရှိတဲ့ ပြဿနာများ

Merchant တွေအတွက် ငွေပေးချေမှု လက်ခံရမှာ ဖြစ်လေ့ဖြစ်ထရှိတဲ့ ပြဿနာလေးတွေကတော့

(၁) Merchant တွေဆီမှာ approved ဖြစ်ခဲ့တဲ့ transaction တွေအတွက် ငွေမဝင်တာပါ။ များသောအားဖြင့် settlement မှာ delay ကြောင့် ဖြစ်နိုင်ပါတယ်။ Settlement files တွေ process လုပ်ပြီးမပြီးနဲ့ cut-off လုပ်တဲ့ အချိန်တွေ စစ်ဆေးရပါမယ်။

(၂) ငွေပေးချေမှု တစ်ခုအတွက် ဝယ်သူဆီမှာ ငွေနှစ်ခါ ဖြတ်မိတာပါ။ ငွေပေးချေမှုလုပ်တဲ့ အချိန်မှာ timeout ဖြစ်သွားတာကြောင့် တစ်ကြိမ်ထက်ပိုပြီး ငွေပေးချေဖို့ reattempt တွေ လုပ်မိတာကြောင့် ဖြစ်နိုင်ပါတယ်။ Multiple attempt လုပ်မိတာအတွက် reversal ဖြစ်ထားတာ ရှိမရှိနဲ့ duplicate authorization လုပ်ခဲ့မိတာ ရှိမရှိ စစ်ဆေးရပါမယ်။

(၃) Transaction မအောင်မြင်ဘဲ ငွေပေးချေသူရဲ့ ကတ်၊ အကောင့်တွေထဲကနေ ပိုက်ဆံလျော့သွားတာပါ။ Issuer သို့မဟုတ် provider တွေဆီမှာ ငွေကို on-hold ဖြစ်နေတာ ဖြစ်နိုင်ပါတယ်။ Reversals သို့မဟုတ် void လုပ်လိုက်ရင် အဆင်ပြေသွားတတ်ပါတယ်။

(၄) ဝယ်သူက QR scan ဖတ်လိုက်ပေမယ့် merchant ဆီမှာ ငွေပေးချေမှု အောင်မြင်ကြောင်း ပေါ်မလာတာပါ။ Callback နောက်ကျနေတာ ဖြစ်နိုင်ပါတယ်။ Provider system ရဲ့ notification logs တွေကို စစ်ဆေးကြည့်ပါ။

(၅) POS စက် လိုင်းမတက်တာပါ။ Merchant သို့ဟုတ် acquirer ဆီမှာ network ကွန်ရက် သို့မဟုတ် system issue ရှိနေတာကြောင့် ဖြစ်နိုင်ပါတယ်။ Network နဲ့ system တွေ ပုံမှန်အခြေအနေရှိမရှိ စစ်ဆေးကြည့်ပါ။

“Payments Made Simple” 40 day series - day 17 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 18 - Cross-Border Payments နဲ့ Domestic Payment ဘာကွာသလဲ

ပုံမှန်အားဖြင့် ပြည်တွင်းမှာ ငွေပေးချေတာနဲ့ ပြည်ပမှာ ငွေပေးချေတာတွေမှာ user experience ကိုပဲ ပြောရရင် ဘာမှ မကွာသလိုပါပဲ။ ဒါပေမယ့် သေချာပေါက် မတူညီတဲ့ ကွာခြားချက်တွေ ရှိနေပါတယ်။

(၁) ပထမဆုံး ကွာခြားချက်ကတော့ exchange rate ပဲ ဖြစ်ပါတယ်။ နိုင်ငံခြားငွေနဲ့ ငွေပေးချေရမှာမို့ currency exchange ဖြစ်စဉ် ပါဝင်လာပါတယ်။ Payment လုပ်တဲ့အခါမှာ ကိုယ်ငွေပေးချေတဲ့ နိုင်ငံရဲ့ currency နဲ့ exchange လုပ်ပြီး process လုပ်ခံရမှာ ဖြစ်ပါတယ်။ ဒီနေရာမှာ ပြည်တွင်းမှာ ငွေပေးချေတာ ဖြစ်ပေမယ့် နိုင်ငံခြား ecommerce merchant တွေဆီနေ ပစ္စည်းတွေ ဝယ်ယူတဲ့အခါမှာလည်း merchant currency အပေါ်မူတည်ပြီး currency exchange ဖြစ်စဉ် ပါဝင်လာမှာ ဖြစ်ပါတယ်။

(၂) Markup fee နဲ့ foreign transaction fee တွေလည်း ကောက်ခံရနိုင်ပါတယ်။ Markup fee ဆိုတာကတော့ exchange rate အပေါ်မှာ ရာခိုင်နှုန်း ပမာဏ တစ်ခုတင်ထားပြီး currency exchange လုပ်ပေးရတာအတွက် ကောက်ခံတာပါ။ Foreign transaction fee ကတော့ နိုင်ငံပြင်ပမှာရှိတဲ့ merchant ဆီမှာ စျေးဝယ်တဲ့အတွက်ဆိုပြီး ကောက်ခံတာပါ။

(၃) အကြောင်းကြောင့် return နဲ့ refund တွေ လုပ်တဲ့အခါတွေမှာ မတူညီတဲ့ ငွေကြေး currency တွေနဲ့ exchange လုပ်ပြီး process လုပ်ထားတာဖြစ်လို့ ပြန်ရတဲ့အခါမှာ ကိုယ်ပေးချေခဲ့တဲ့ ငွေပမာဏအတိုင်း အတိအကျ ပြန်မရတာ၊ ငွေကြေးဆုံးရှုံးတာတွေ ဖြစ်နိုင်ပါတယ်။ ‌Exchange rate အပြောင်းအလဲ၊ ကောက်ခံထားတဲ့ fee နဲ့ payment provider တွေရဲ့ စည်းမျဉ်းတွေ အပေါ်မူတည်ပြီး ငွေပမာဏအချို့ ဆုံးရှုံးနိုင်တာ ဖြစ်ပါတယ်။

“Payments Made Simple” 40 day series - day 18 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 19 - Digital Payment တွေမှာ ဖြစ်တတ်တဲ့ လိမ်လည်မှုများ

အသုံးပြုတဲ့ ငွေပေးချေမှုနည်းလမ်းပေါ် မူတည်ပြီး လိမ်လည်မှု fraud လုပ်ခံရတဲ့ ဖြစ်စဉ်တွေ အမျိုးမျိုးရှိပါတယ်။ ဖြစ်လေ့ဖြစ်ထရှိတဲ့ fraud ဖြစ်စဉ်တွေကတော့

(၁) ကတ်အချက်အလက်၊ အကောင့်အချက်အလက်တွေနဲ့ OTP တွေ ခိုးယူခံရတာ၊ ပေါက်ကြားတာ ဖြစ်ပါတယ်။ Login page အတုတွေနဲ့ phishing အလုပ်ခံရတာ၊ အကောင့်ပိုင်ရှင်နဲ့ ရင်းနှီးမှုရယူပြီး social engineering နည်းနဲ့ အချက်အလက်တွေ ရယူတာတွေကြောင့် ဖြစ်လေ့ရှိပါတယ်။

(၂) အွန်လိုင်းကနေ စျေးဝယ်တာမှာ ရိုးသားမှုမရှိတဲ့ merchant တွေကနေ ရောင်းချထားတဲ့ ပစ္စည်းမဟုတ်တာ၊ အရည်အသေး မမှီတာတွေ ပို့ပေးတာ၊ သို့မဟုတ် ငွေရပြီးနောက် ပစ္စည်းမပို့ပေးတာတွေ ဖြစ်ပါတယ်။

(၃) Account takeovers အလုပ်ခံရတာ ဖြစ်ပါတယ်။ ကိုယ့်ရဲ့ wallet အကောင့်၊ ဘဏ်အကောင့်နဲ့ ecommerce app အကောင့်စတာတွေကို လိမ်လည်သူတွေက ခိုးယူရရှိသွားပြီး အကောင့်ထဲက ငွေတွေကို အခြားကို ငွေလွှဲတာ၊ ငွေပေးချေတာ၊ အကောင့်နဲ့ စျေးဝယ်တာတွေ ပြုလုပ်တာ ဖြစ်ပါတယ်။

(၄) Friendly fraud လို့ခေါ်တဲ့ စျေးဝယ်သူ customer တွေက ဝယ်ယူထားတဲ့ ပစ္စည်းကို delivery လက်ခံရရှိထားပေမယ့် မရပါဘူးဆိုပြီး လိမ်လည် complaint တက်တာ၊ သို့မဟုတ် ကတ်ပိုင်ရှင်၊ အကောင့်ပိုင်ရှင်ရဲ့ မိသားစုဝင်တွေက ကတ်၊ အကောင့်ကို သုံးပြီး စျေးဝယ်ထားတာကို မသိထားတာကြောင့် အခိုးခံရတယ်ထင်ပြီး complaint တက်တာတွေ ဖြစ်တတ်ပါတယ်။

“Payments Made Simple” 40 day series - day 19 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 20 - Merchant Discount Rate (MDR) ဆိုတာ

Merchant တွေအနေနဲ့ online ဖြစ်စေ in-store ဖြစ်စေ ‌digital payment တွေနဲ့ ငွေပေးချေမှု လက်ခံရာမှာ Merchant Discount Rate (MDR) ကို ဝန်ဆောင်ခအနေနဲ့ ပေးရမှာပါ။

MDR fee တွေမှာ merchant နဲ့ acquirer ကြားက သဘောတူညီချက်ပေါ်မူတည်ပြီး အများဆုံး တွေ့ရတဲ့ ငွေကောက်ခံမှု ပုံစံတွေကတော့ transaction amount ရဲ့ percentage တစ်ခုကို fixed % rate အနေနဲ့ဖြစ်စေ၊ transaction တစ်ကြောင်းစီအတွက် ဘယ်လောက်ကောက်ယူမယ်လို့ သတ်မှတ်ထားတဲ့ fixed amount အနေနဲ့ဖြစ်စေ၊ fixed % rate နဲ့ fixed amount နှစ်မျိုး ပေါင်းစပ် ကောက်ခံတဲ့ blended pricing နဲ့ ဖြစ်စေ ပေးဆောင်ရလေ့ ရှိပါတယ်။

(Fixed % rate မှာဆို ၃% MDR သတ်မှတ်ထားရင် ၁၀,၀၀၀ ကျပ်တန် ငွေပေးချေမှု အတွက် merchant က ၉,၇၀၀ ကျပ် ရမှာပါ။ Fixed amount မှာဆို transaction တစ်ကြောင်း အတွက် ၂၀၀ ကျပ် သတ်မှတ်ထားရင် merchant က ၉,၈၀၀ ကျပ် ရမှာပါ။ Fixed % နဲ့ amount နှစ်မျိုးပေါင်းပြီး ၁% နဲ့ ၂၀၀ ကျပ် ကောက်ခံတာဆိုရင် merchant အနေနဲ့ ၉,၇၀၀ ကျပ် ရမှာပါ။)

အဲ့ဒီကောက်ခံထားတဲ့ငွေတွေကို payer’s payment provider (issuer) ၊ payee’s payment provider (acquirer) နဲ့ payment scheme (network) အစရှိတဲ့ party တွေက ခွဲဝေရရှိမှာပါ။ Merchant တွေကို ငွေလက်ခံနိုင်အောင်၊ မတူညီတဲ့ payment တွေနဲ့ interoperate လုပ်နိုင်အောင် system တွေ၊ infrastructure တွေ တည်ဆောက်ပေးထားရပြီး အမြဲတမ်းလည်ပတ်နိုင်စေအောင် စနစ်နဲ့ ဝန်ဆောင်မှုတွေ ထောက်ပံ့ပေးထားရလို့ ပေးဆောင်ရတာ ဖြစ်ပါတယ်။

MDR fee က ပုံသေမဟုတ်ပါဘူး။ Transaction volume နဲ့ amount များများ process လုပ်လာရတဲ့အခါ merchant တွေအနေနဲ့ သက်ဆိုင်ရာ acquirer တွေနဲ့ ညှိနိုင်းပြီး ပိုမိုသက်သာတဲ့ MDR fee နဲ့ ငွေလက်ခံနိုင်ဖို့ ညှိနှိုင်းပြီး ဝန်ဆောင်ခကို လျှော့ချနိုင်ပါတယ်။

“Payments Made Simple” 40 day series - day 20 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 21 - ISO 8583 သို့မဟုတ် Card System တွေရဲ့ ဘာသာစကား

Card payment system တွေကြားမှာ အချင်းချင်း communicate လုပ်ဖို့အတွက် ISO 8583 လို့ခေါ်တဲ့ standard messaging format ကို အသုံးပြုပါတယ်။ အထူးသဖြင့် acquirer နဲ့ card scheme ကြား၊ card scheme နဲ့ issuer တွေကြားမှာ ISO 8583 ကို အသုံးပြုပြီး communicate လုပ်ပါတယ်။ ISO 8583 message မှာ 1987 ၊ 1993 နဲ့ 2003 အစရှိသဖြင့် version ၃မျိုးရှိပြီး တွင်တွင်ကျယ်ကျယ် အသုံးပြုနေတာကတော့ 1987 ထွက် version ပဲ ဖြစ်ပါတယ်။ ISO 8583 message တွေမှာ အဓိကအားဖြင့် အပိုင်း(၃)ပိုင်း ရှိပါတယ်။

၁) ပထမဆုံးတစ်ခုကတော့ MTI (Message Type Indicator) ဖြစ်ပြီး 4-digit numeric field ဖြစ်ပါတယ်။ Digit 1 မှာ အသုံးပြုထားတဲ့ ISO 8583 message version ကို ဖော်ပြပါတယ်။ Digit 2 မှာ message က authorization message လား၊ financial message လား၊ network management message လား အစရှိသဖြင့် message ရဲ့ purpose ကို ဖော်ပြပါတယ်။ Digit 3 မှာ request လား၊ response လား အစရှိသဖြင့် message ရဲ့ function ကို ဖော်ပြပါတယ်။ Digit 4 မှာ acquirer ဆီက လာသလား၊ issuer ဆီကလာသလား အစရှိသဖြင့် message ရဲ့ စတင်ရာ origin ကို ဖော်ပြပါတယ်။

၂) ဒုတိယတစ်ခုကတော့ Bitmaps ဖြစ်ပြီး အဲ့ဒီ bitmap တွေကို အသုံးပြုပြီး message တစ်ခုချင်းစီမှာ ပါဝင်မယ့် data element တွေကို ဖော်ပြပါတယ်၊ ခွဲခြားကြပါတယ်။

၃) နောက်ဆုံးတစ်ခုကတော့ Data elements (data fields) တွေဖြစ်ပြီး transaction တစ်ခုချင်းစီရဲ့ အသေးစိတ် အချက်အလက်တွေကို ဖော်ပြပေးပါတယ်။ ကတ်နံပါတ်၊ အသုံးပြုတဲ့ timestamp ၊ merchant အချက်အလက်၊ ငွေပမာဏ၊ respond codes အစရှိသဖြင့် transaction ရဲ့ detailed အချက်အလက်တွေကို ဖော်ပြပါတယ်။

နောက်တစ်ပိုင်းမှာတော့ အသုံးများတဲ့ သိထားသင့်တဲ့ data elements တွေကို ဆက်ပြီး မျှဝေပေးပါမယ်။

“Payments Made Simple” 40 day series - day 21 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 22 - Card Payments အတွက် သိထားရမယ့် ISO 8583 Data Element များ

Card payment အတွက် မဖြစ်မနေ သိထားရမယ့် ISO 8583 data element fields တွေကတော့

[DE 2] Primary Account Number (PAN) - ကတ်နံပါတ် ဖြစ်ပါတယ်။ Visa ၊ Mastercard ၊ MPU အစရှိသဖြင့် ကတ် brand နဲ့ ကတ်ထုတ်ပေးထားတဲ့ issuer ကို ခွဲခြားသိနိုင်စေပါတယ်။

[DE 3] Processing Code - Purchase လား၊ refund လား၊ withdrawal လား အစရှိသဖြင့် transaction အမျိုးအစားကို ခွဲခြားပေးတဲ့ 6 digit ကုဒ်ဖြစ်ပါတယ်။

[DE 4] Transaction Amount - အသုံးပြုလိုက်တဲ့ ငွေပမာဏ ဖြစ်ပါတယ်။ Issuer ၊ acquirer နဲ့ card scheme တွေကြားမှာ တူညီနေဖို့လိုအပ်ပြီး reconciliation အတွက် အရေးကြီးပါတယ်။

[DE 11] System Trace Audit Number (STAN) - ATM ၊ POS အစရှိတဲ့ terminal တွေကနေ သတ်မှတ်ပေးတဲ့ trace number ဖြစ်ပြီး 6 digit နံပါတ်တွဲ ဖြစ်ပါတယ်။

[DE 18] Merchant Category Code (MCC) - Retail လား၊ travel လား အစရှိသဖြင့် merchant ရဲ့ business အမျိုးအစားကို ခွဲခြားဖို့သုံးတဲ့ 4 digit ကုဒ်ဖြစ်ပါတယ်။

[DE 37] Retrieval Reference Number (RRN) - Acquirer ကနေ ထုတ်ပေးတဲ့ transaction အတွက် unique reference ဖြစ်ပြီး 12 characters ပါဝင်တဲ့ ကုဒ်ဖြစ်ပါတယ်။

[DE 39] Response Code - Transaction တစ်ခု approved ဖြစ်တယ်၊ ဘာကြောင့် rejected ဖြစ်တယ်ဆိုတဲ့ result ကို ဖော်ပြပေးတဲ့ 2 digit ကုဒ်ဖြစ်ပါတယ်။

[DE 41] Card Acceptor Terminal ID (TID) - အသုံးပြုတဲ့ ATM ၊ POS အစရှိတဲ့ terminal ရဲ့ ID ကို ဖော်ပြပါတယ်။

[DE 42] Card Acceptor Identification Code (MID) - အသုံးပြုတဲ့ merchant ရဲ့ ID ကို ဖော်ပြပါတယ်။

[DE 49] Transaction Currency Code - Transaction ပြုလုပ်တဲ့ currency ကို ဖော်ပြပါတယ်။

“Payments Made Simple” 40 day series - day 22 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 23 - Card Payment Transaction များကို Trace လုပ်ခြင်း

Card payment transaction တွေကို စစ်ဆေးတဲ့အခါမှာ transaction flow ရဲ့ ဘယ်နေရာမှာ ပြဿနာရှိသလဲဆိုတာ သိရအောင် transaction journey အတိုင်း စစ်ကြည့်နိုင်ပါတယ်။

(၁) ငွေပေးချေလို့ မရဘူးလို့ complaint ရတဲ့အခါမှာ cardholder က ဘယ်နေ့ ဘယ်ရက် ဘယ်အချိန်မှာ ဘာ transaction လုပ်ခဲ့တာလဲ၊ ဘယ်လိုလုပ်ခဲ့တာလဲဆိုတဲ့ cardholder action ကို အရင်ဆုံး သိအောင် မေးရပါမယ်၊ confirm လုပ်ရပါမယ်။

(၂) ပြီးတော့ merchant ရဲ့ POS စက်၊ ecommerce app တွေကနေ transaction request ကို acquirer ဆီ ပို့လိုက်နိုင်ရဲ့လားဆိုတာ စစ်ဆေးရပါမယ်။ Transaction failure တော်တော်များများမှာ POS စက် နဲ့ merchant app တွေကနေ transaction ကို ပို့မပေးနိုင်တာကြောင့် ဖြစ်တတ်ပါတယ်။

(၃) အဲ့ဒီနောက် ကိုယ်က acquire side မှာဆို acquirer ကနေ card scheme ဆီ transaction ပို့လိုက်နိုင်သလား၊ issuer side မှာဆို card scheme ကနေ transaction ကို လက်ခံရရှိထားသလား စစ်ဆေးရပါမယ်။ Transaction ကို မပို့လိုက်နိုင်ဘူး သို့မဟုတ် မရထားဘူးဆိုရင် configuration ကြောင့်နဲ့ connectivity တွေကြောင့် ဖြစ်နိုင်ပါတယ်။

(၄) နောက်ဆုံးမှာတော့ issuer ရဲ့ decision ကို စစ်ရမှာ ဖြစ်ပါတယ်။ Issuer ဆီကနေ approve သို့မဟုတ် decline လုပ်တဲ့ transaction response ကို ပြန်ပေးထားသလား၊ ရထားသလားစစ်ပါ။ Issuer ဆီက decline ဖြစ်ထားတဲ့ transaction တွေအတွက် response code ကို ကြည့်ပြီး ဘာကြောင့် transaction failure ဖြစ်သလဲဆိုတာကို သိနိုင်ပါတယ်။

Transaction အဆင့်တိုင်းမှာ လိုက်ကြည့်မယ်ဆိုရင် flow ဘယ်နေရာမှာ ပြတ်သွားသလဲ၊ ဘာကြောင့်လဲဆိုတာ သိရမှာ ဖြစ်ပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ day 23 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 24 - Card Management System ၊ Switch နဲ့ Core Banking အကြောင်း

- Card Management System (CMS) ကတော့ ကတ်အကောင့်တွေ၊ cardholder profile တွေ၊ credit limit ၊ ကတ် limit တွေနဲ့ available balance တွေကို သိမ်းဆည်းတာ၊ စီမံခန့်ခွဲတာတွေ လုပ်ပေးပါတယ်။ ပြီးတော့ ကတ်ထုတ်ဝေတဲ့ card issuance လုပ်ငန်းစဉ်တွေ၊ transaction posting လုပ်တာတွေ၊ interest calculation တွေနဲ့ credit card ကိုင်‌ဆောင်သူတွေအတွက် လစဉ် monthly statement ထုတ်ပေးတာတွေကို လုပ်ပါတယ်။

- Card Payment Switch ကတော့ card network တွေနဲ့ backend system တွေကြားမှာ routing နဲ့ switching ကို အဓိက လုပ်ပေးပါတယ်။ Card network ကနေ ISO 8583 messaging format နဲ့ transaction တွေကို ဝင်လာတဲ့အခါ ကတ်အမျိုးအစားအပေါ် မူတည်ပြီး သက်ဆိုင်ရာ system တွေဆီကို route လုပ်ပေးပါတယ်။ Debit ကတ် transaction တွေအတွက် core banking ဆီကို route လုပ်ပေးပြီး account နဲ့ balance အချက်အလက်တွေတောင်းခံတာ၊ approval ယူတာတွေ လုပ်ပေးပါတယ်။ Credit ကတ်၊ prepaid ကတ်တွေအတွက်ကတော့ card management system ကနေ လုပ်ပေးပါတယ်။

- Core Banking System ကတော့ customer တွေရဲ့ အချက်အလက်တွေ၊ ဘဏ်အကောင့် အချက်အလက်တွေအတွက် source of truth ဖြစ်ပါတယ်။ Debit card transaction တွေအတွက် real-time balance ကို ကိုင်တွယ်ပြီး approval လုပ်ပေးပါတယ်။ Credit card တွေ၊ prepaid card တွေအတွက်တော့ real-time ထိတွေ့ရတဲ့အပိုင်း မရှိပါဘူး။ ဒါပေမယ့် card payments system တွေနဲ့ ဆက်စပ်စနစ်တွေ အားလုံးမှာ နေ့စဉ်ဖြစ်နေတဲ့ overall portfolio တွေကတော့ ဘဏ်ရဲ့ financial အချက်အလက်တွေအားလုံးရဲ့ source ဖြစ်တဲ့ core banking system မှာ maintain လုပ်ထားမှာ ဖြစ်ပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ day 24 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 25 - Payment မအောင်မြင်ရတဲ့ Root Cause ချက်ချင်း သိနိုင်ဖို့

ငွေပေးချေမှု payment တွေ မအောင်မြင်ဘဲ fail ဖြစ်တဲ့အခါ အသေးစိတ် စစ်တာတွေ၊ technical log ကြည့်တာတွေ မလုပ်ပါနဲ့ဦး။ အကြောင်းရင်း root cause ကို အလွယ်တကူနဲ့ ချက်ချင်းသိနိုင်တဲ့ ဒီအချက်တွေကို အရင်ဆုံး စစ်ကြည့်ပါ။

(၁) ငွေပေးချေသူ customer ကြောင့် ဖြစ်တတ်တဲ့ issue လား စစ်ပါ။ Customer တွေကြောင့် ဖြစ်တတ်တာတွေကတော့ PIN ၊ OTP တွေ မှားရိုက်မိတာ၊ ကတ်သက်တမ်းကုန်နေတာ၊ အကောင့်တွေ ကတ်တွေ PIN တွေ lock ကျနေတာ၊ လက်ကျန်ငွေ balance မလုံလောက်တာတွေပါ။

(၂) Merchant ကြောင့် ဖြစ်တတ်တဲ့ issue လား စစ်ပါ။ POS စက် လိုင်းမတက်ဘဲ offline ဖြစ်နေတာ၊ QR code ထုတ်မပေးနိုင်တာ၊ online ecommerce ငွေပေးချေရာမှာ checkout အဆင့်ကနေ ဆက်မသွားနိုင်ဘဲ error တက်နေတာ အစရှိတာတွေပါ။

(၃) Acquirer ရဲ့ transaction routing မှာ ဖြစ်တတ်တဲ့ issue လား စစ်ပါ။ Transaction request တွေ issuer ဆီကို မရောက်တဲ့၊ မပို့နိုင်တဲ့ case တော်တော်များများမှာ configuration တွေ၊ merchant setup တွေ မှားယွင်းနေတာကြောင့်နဲ့ network ပြဿနာရှိနေတာတွေကြောင့် ဖြစ်တတ်ပါတယ်။

(၄) Issuer ၊ mobile wallet အစရှိသဖြင့် customer ကို payment instrument တွေ ထုတ်ပေးထားတဲ့ provider ရဲ့ response ကြောင့်ဖြစ်တတ်တဲ့ issuer လား စစ်ပါ။ Issuer တွေ၊ wallet provider တွေ ဆီက ပြန်လာတဲ့ response code တွေကို ကြည့်ပြီး ဘာကြောင့် payment မအောင်မြင်တာလဲဆိုတာကို ခွဲခြားသိနိုင်ပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ day 25 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 26 - QR Payment နဲ့ Card Payment တွေရဲ့ Posting Logic

QR scan ကိုသုံးပြီး wallet နဲ့ mobile payment တွေလုပ်တဲ့အခါမှာ ငွေပေးချေသူ customer ရဲ့ app ကနေ scan ဖတ်လိုက်တာနဲ့ customer ရဲ့ payment provider ဆီ transaction ရောက်သွားပြီး validation လုပ်ပါတယ်။ Customer ရဲ့ provider ဆီကနေ transaction ကို ခွင့်ပြုပေးလိုက်ပြီဆိုတာနဲ့ customer ရဲ့ mobile payment account ထဲကနေ ငွေချက်ချင်း ဖြတ်သွားမှာပါ။ ဒီအခြေအနေမှာ merchant တွေအနေနဲ့ကတော့ transaction အောင်မြင်ကြောင်း notification ရမှာ ဖြစ်ပါတယ်။ ချိတ်ဆက်ထားတဲ့ QR စနစ်နဲ့ acquirer ပေါ်မူတည်ပြီး merchant တွေအတွက် ငွေချက်ချင်းရတာ ဖြစ်နိုင်သလို settlement process တွေလုပ်ဆောင်ပြီး နောက်ရက်မှ ငွေရတာလည်း ဖြစ်နိုင်ပါတယ်။

ကတ်အသုံးပြုပြီး ငွေပေးချေတဲ့ transaction တွေမှာတော့ များသောအားဖြင့် POS စက်ကနေ ငွေပေးချေလိုက်တဲ့အခါမှာ issuer ဆီကနေ လိုအပ်တာတွေ စစ်ဆေးပြီး transaction ကို ခွင့်ပြုပေးလိုက်ပါတယ်။ ဒီအဆင့်မှာ customer ရဲ့ ကတ်ထဲကနေ ငွေကို ချက်ချင်း မဖြတ်သေးပါဘူး။ On-hold လုပ်ထားလိုက်ပါတယ်။ သဘောတရားကတော့ ကတ်ထဲက ငွေကို မနှုတ်ယူရသေးပါဘူး။ အသုံးပြုလိုက်တဲ့ ငွေပမာဏကိုပဲ ထပ်ပြီး မသုံးနိုင်အောင် ခဏတာ ထိန်းသိမ်းထားတာပါ။ Available Balance လျော့သွားပါမယ်၊ account balance မနှုတ်ရသေးပါဘူး။ Settlement process တွေ အားလုံးပြီးတဲ့အခါကျမှ ကတ်ထဲကငွေကို အမှန်တစ်ကယ် နှုတ်ယူမှာပါ။ Merchant တွေအနေနဲ့လည်း settlement process တွေ လုပ်ဆောင်ပြီးတဲ့အခါကျမှ ငွေလက်ခံရရှိမှာပါ။

(40-day “Payments Made Simple” series ရဲ့ day 26 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 27 – Authorization vs Posting အကြောင်း

- Authorization ကတော့ issuer ၊ wallet provider အစရှိတာတွေကနေ transaction ကို real-time အသုံးပြုခွင့်ပြုမယ်၊ မပြုဘူးဆိုတဲ့ decision ချပေးတာဖြစ်ပါတယ်။ ငွေပေးချေမှုလုပ်တဲ့အခါ လက်ကျန်ငွေ balance ၊ အသုံးပြုခွင့် limit ၊ account status နဲ့ fraud rules အစရှိတာတွေကို စစ်ဆေးပြီးနောက် transaction အသုံးပြုခွင့် approved ပေးလိုက်တာ သို့မဟုတ် ငြင်းပယ်တာ denied လုပ်ပါတယ်။ အဲ့ဒီအတည်ပြုချက်ကို merchant တွေဆီမှာ ချက်ချင်း လက်ခံရရှိမှာပါ။ ဒါပေမယ့် ဒီအဆင့်မှာ money movement တွေ အမှန်တစ်ကယ် မဖြစ်သေးပါဘူး။ Authorization အဆင့်မှာ ငွေပမာဏကို reserve လုပ်ပြီး ဖယ်ထားလိုက်တာနဲ့၊ အသုံးပြုမှု အတည်ပြုပြီး ခွင့်ပြုချက်ချပေးတာတွေကိုပဲ လုပ်ဆောင်မှာပါ။

- Posting ကတော့ transaction ရဲ့ ရလဒ်ပေါ် မူတည်ပြီး customer နဲ့ merchant ရဲ့ record တွေ၊ account တွေကို update လုပ်ပေးတာ ဖြစ်ပါတယ်။ Clearing file တွေကို အသုံးပြုပြီး posting လုပ်တာဖြစ်နိုင်သလို၊ callbacks တွေ သို့မဟုတ် internal confirmation တွေအပေါ် မူတည်ပြီး posting လုပ်ဆောင်တာလည်း ဖြစ်နိုင်ပါတယ်။ Posting ပြီးတဲ့အခါမှ customer ရဲ့ အကောင့်ထဲက ငွေအမှန်တစ်ကယ် ဖြတ်သွားတာနဲ့ merchant တွေအတွက် ငွေအမှန်တစ်ကယ် ရရှိတာတွေ ဖြစ်မှာပါ။

(40-day “Payments Made Simple” series ရဲ့ day 27 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 28 – Reconciliation ဆိုတာ

Reconciliation ဆိုတာကတော့ payment systems တွေမှာ ရှိနေတဲ့ transaction record တွေ၊ ငွေစာရင်းတွေနဲ့ တစ်ကယ့် money flow ကိုက်ညီမှု ရှိမရှိ စစ်ဆေးတဲ့ လုပ်ငန်းစဉ် ဖြစ်ပါတယ်။ ငွေပေးချေမှု လက်ခံတဲ့ merchant ဖြစ်စေ၊ acquirer ဖြစ်စေ၊ issuer ဖြစ်စေ ငွေစာရင်းတွေ မှန်ကန်မှုရှိတာ သေချာဖို့အတွက် reconciliation ကို မဖြစ်မနေ လုပ်ကြရပါတယ်။

Reconciliation လုပ်ရာမှာ merchant တွေရဲ့ transaction record တွေ၊ acquirer တွေ issuer တွေရဲ့ report တွေ၊ clearing file တွေနဲ့ settlement result တွေကို တစ်ခုနဲ့တစ်ခု ကိုက်ညီမှု ရှိမရှိ တိုက်ဆိုင်စစ်ဆေးကြပါတယ်။ ငွေပမာဏ၊ အသုံးပြုတဲ့ ငွေကြေး currency အမျိုးအစားနဲ့ transaction အရေအတွက် အစရှိတာတွေမှာ အပို အလို ရှိမရှိ၊ လွဲမှားနေတာ ရှိမရှိ တိုက်ဆိုင်စစ်ဆေးကြ၊ ရှာဖွေကြပါတယ်။ ပြီးတော့ စစ်ဆေးရာမှာ မကိုက်ညီတဲ့ record တွေရှိနေတယ်ဆိုရင် ဘယ်နေရာမှာ လွဲနေသလဲ၊ ဘာကြောင့်လွဲနေသလဲဆိုတာကို အဖြေရှာပြီး စာရင်းမှန်ကန်သွားအောင် ဖြေရှင်းရပါတယ်။

Reconciliation ကြောင့် merchant ၊ acquirer ၊ issuer ၊ payment processor ၊ payment network (scheme) အစရှိသဖြင့် payment process မှာပါဝင်တဲ့ party တွေ အားလုံးကြားမှာ တူညီတဲ့ မှန်ကန်တဲ့ ငွေစာရင်းတွေ ရှိနေတာကို သေချာစေပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ day 28 အတွက် ဖြစ်ပါတယ်။ Payments ဆိုင်ရာ အကြောင်းအရာတွေကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 29 - Settlement Files တွေ ကိုင်တွယ်တဲ့အခါ သတိထားရမယ့် အချက်များ

Payment transaction တွေရဲ့ settlement data တွေ မှန်မှန်ကန်ကန်နဲ့ အမှားအယွင်း မရှိစေဖို့ ဒီအချက်တွေကို ဂရုစိုက်သင့်ပါတယ်။

(၁) Settlement file တွေမှာပါဝင်တဲ့ header နဲ့ trailer တွေကို အရင်ဆုံး စစ်ဆေးပါ။ ဖိုင်ထဲမှာ ပါဝင်တဲ့ record count တွေ၊ total debit amount ၊ total credit amount တွေ၊ file datetime နဲ့ sequence number တွေ မှန်ကန်မှုရှိမရှိ စစ်ဆေးပါ။

(၂) Settlement file မှာပါဝင်တဲ့ net settlement amount ကို system ကနေ ထုတ်ယူထားတဲ့ authorized transaction တွေရဲ့ စုစုပေါင်း ပမာဏနဲ့ ကိုက်ညီမှုရှိမရှိ စစ်ဆေးပါ။ ဒီနေရာမှာ transaction အကုန်လုံး settled မလုပ်ရသေးတာ၊ မတူညီတဲ့ different party (system) တွေကြား timing ကွာဟချက်၊ cut-off လုပ်တဲ့ အချိန် ကွာဟချက်တွေကြောင့် စာရင်းမကိုက်ညီတာတွေ ဖြစ်တတ်ပါတယ်။

(၃) MDR fee တွေ၊ interchange fee တွေ၊ service charges တွေကို သတ်မှတ်ထားတဲ့ transaction အမျိုးအစားအလိုက် မှန်ကန်စွာ တွက်ချက်ထားသလား စစ်ဆေးပါ။

(၄) Failed ဖြစ်ထားတဲ့ transaction တွေ၊ chargeback တွေ၊ reversal ဖြစ်ထားတဲ့ transaction တွေ အစရှိသဖြင့် ပုံမှန် transaction မဟုတ်တာတွေ settlement မှာ ပါနေသလားစစ်ပါ။ အကယ်၍ အဲ့ဒီလို transaction တွေ ပါနေခဲ့ရင် မှန်ကန်မှုရှိမရှိ သတိထားပြီး စစ်ပေးပါ။

နောက်ဆုံးအနေနဲ့ settlement file တွေကို ကိုင်တွယ်တဲ့အခါမှာ စစ်ဆေးတဲ့ process တွေကို manual လုပ်တာထက် automation နဲ့ အလိုအလျောက် လုပ်ဆောင်နိုင်အောင် စီစဉ်ထားသင့်ပါတယ်။ Automation ကြောင့် exception case တွေလောက်ပဲ manual စစ်ဖို့ လိုတော့မှာဖြစ်လို့ အချိန်ကုန်သက်သာသွားသလို၊ human error ကိုလည်း လျှော့ချနိုင်မှာ ဖြစ်ပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ day 29 အတွက် ဖြစ်ပါတယ်။ Payments အကြောင်း၊ Payments System တွေအကြောင်းကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

https://payzillion.com/
https://www.facebook.com/PayZillion/

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 30 - Authorization နဲ့ Settlement ကြားက အလွဲများ

Authorized ဖြစ်ထားတဲ့ transaction တွေနဲ့ settled ဖြစ်သွားတဲ့ transaction တွေမှာ အကြောင်းရေ မတူညီတာတွေရော၊ transaction တစ်ကြောင်းချင်းစီအတွက် ငွေပမာဏ မတူညီတာတွေရော ဖြစ်နိုင်ပါတယ်။ မတူတဲ့ အခါတိုင်းမှာ မှားနေတာတော့ မဟုတ်ပါဘူး။ ဖြစ်တတ်တဲ့ အလွဲအချို့ကတော့

(၁) မတူညီတဲ currency တွေကြား transaction တွေ process လုပ်ရတဲ့အခါ approved ဖြစ်ခဲ့တဲ့ အချိန်နဲ့ settled ဖြစ်တဲ့အချိန်ရဲ့ currency exchange rate ကွာဟချက်တွေကြောင့် transaction approved ဖြစ်ထားတဲ့ ငွေပမာဏနဲ့ settled ဖြစ်တဲ့ ငွေပမာဏ မတူညီတာတွေ ဖြစ်တတ်ပါတယ်။

(၂) Transaction က approved ဖြစ်ထားပေမယ့် merchant တွေဆီမှာ ငွေမဝင်တာပါ။ Technical error ကြောင့်ဖြစ်စေ၊ human error ကြောင့်ဖြစ်စေ transaction တွေ မှန်ကန်စွာ settled မဖြစ်တဲ့၊ မလုပ်မိတဲ့ အခါတွေမှာ ဒီလိုဖြစ်တတ်ပါတယ်။

(၃) တူညီတဲ့ transaction တစ်ကြောင်းအတွက် customer ဆီက တစ်ကြိမ်ထက်ပိုပြီး ငွေဖြတ်ထားမိပြီး merchant payout တွေ ပိုဝင်နေတာပါ။ ငွေပေးချေတဲ့အချိန်မှာ error တစ်ခုခုကြောင့် တစ်ကြိမ်ထက်ပိုပြီး attempt လုပ်မိထားတာကြောင့် ဖြစ်နိုင်သလို၊ technical error တွေ human error တွေကြောင့် settlement ကို တစ်ကြိမ်ထက်ပိုပြီး လုပ်မိတဲ့အခါမှာ ဒီလိုဖြစ်တတ်ပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ day 30 အတွက် ဖြစ်ပါတယ်။ Payments အကြောင်း၊ payment system တွေအကြောင်းကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

https://payzillion.com/
https://www.facebook.com/PayZillion/

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 31 - Financial Institution တွေမှာ စစ်တဲ့ KYC/KYB တွေ အကြောင်း

- KYC (Know Your Customer) နဲ့ KYB (Know Your Business) တွေကတော့ ငွေကြေးအဖွဲ့အစည်းတွေဆီကနေ ဝန်ဆောင်မှု ရယူအသုံးပြုမယ့် customer နဲ့ merchant တွေရဲ့ အချက်အလက်တွေကို စစ်ဆေးအတည်ပြုတဲ့ process ဖြစ်ပါတယ်။

- အချက်အလက်တွေကို စစ်ဆေးတဲ့အခါမှာ တစ်ကိုယ်ရေအချက်အလက်၊ လုင်ငန်းဆိုင်ရာ အချက်အလက်တွေသာမက အစိုးရက ထုတ်ပေးထားတဲ့ မှတ်ပုံတင်၊ ၊ လုပ်ငန်းလိုင်စင်လို စာရွက်စာတမ်းအထောက်အထားတွေကိုလည်း စစ်ဆေးကြပါတယ်။ ပြီးတော့ watchlist လို စောင့်ကြည့်စာရင်းမှာပါသလား၊ sanction ထိထားသလား၊ PEP စာရင်းထဲမှာပါနေသလား အစရှိသဖြင့် စစ်ဆေးအတည်ပြုကြပါတယ်။

- သတ်မှတ်ထားတဲ့ KYC/KYB process တွေ စစ်ဆေးအတည်ပြုပြီးမှ ဝန်ဆောင်မှုကို အသုံးပြုခွင့်ပေးမှာပါ။ KYC/KYB တွေကြောင့် onboarding လုပ်ရာမှာ အဆင့်တွေများသွားပေမယ့် compliance ဖြစ်စေဖို့၊ risk တွေကို ကာကွယ်ဖို့အတွက် မဖြစ်မနေ လုပ်ကြရပါတယ်။ KYC/KYB ကို စစ်ဆေးပြီး လိမ်လည်မှု fraud တွေ၊ ငွေကြေးခဝါချမှု money laundering တွေ၊ ခွင့်မပြုထားတဲ့ လူပုဂ္ဂိုလ်နဲ့ စီးပွားရေးလုပ်ငန်းတွေ ငွေကြေးစနစ်ထဲကို ရောက်မလာစေဖို့ ကာကွယ်ကြပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ day 31 အတွက် ဖြစ်ပါတယ်။ Payments အကြောင်း၊ payment system တွေအကြောင်းကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

https://payzillion.com/
https://www.facebook.com/PayZillion/

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 32 - Anti-Money Laundering ဆိုတာ

Financial institutions တွေအတွက် ငွေကြေးခဝါချမှုတွေ၊ သံသယဖြစ်စရာ အသုံးပြုမှုတွေကို ရှာဖွေတားဆီးတဲ့ လုပ်ငန်းစဉ်ကို anti-money laundering (AML) လို့ခေါ်တာ ဖြစ်ပါတယ်။ AML အတွက် အခြေခံအားဖြင့် လုပ်ဆောင်ကြတာတွေကတော့

(၁) ဝန်ဆောင်မှုတွေကို အသုံးပြုမယ့် customer နဲ့ merchant တွေရဲ့ အချက်အလက်တွေကို မှန်ကန်မှုရှိမရှိ စစ်ဆေးအတည်ပြုပါတယ်။ အဲ့ဒီ customer တွေ၊ merchant တွေရဲ့ အချက်အလက် profile အလိုက် အသုံးပြုတဲ့ ဝန်ဆောင်မှု activity တွေ ဆီလျော်မှုရှိမရှိ စစ်ဆေးပါတယ်။

(၂) ပုံမှန်မဟုတ်တဲ့ အသုံးပြုမှု၊ ငွေပေးချေမှုတွေ ရှိမရှိ စောင့်ကြည့် monitor လုပ်ပါတယ်။ ရုတ်တရက် ငွေပမာဏ အများကြီး အသုံးပြုတာ၊ အချိန်တိုအတွင်း ငွေပေးချေမှု အများကြီး လုပ်ဆောင်တာ၊ ပုံမှန်မဟုတ်တဲ့ အပြုအမူနဲ့ high-risk ဖြစ်တဲ့ source တွေကနေ ငွေပေးချေမှုတွေ ပြုလုပ်တာ အစရှိသဖြင့် သံသယဖြစ်ဖွယ် အသုံးပြုမှုတွေကို စောင့်ကြည့်ပါတယ်။

(၃) သံသယဖြစ်စရာ အသုံးပြုမှုတွေကို တွေ့ရှိတဲ့အခါ ငွေကြေးအဖွဲ့အစည်းတွေအနေနဲ့ အသုံးပြုခွင့်ကို ခေတ္တဆိုင်းငံတာ၊ reject လုပ်ပြီး ငြင်းပယ်တာတွေ၊ ပြန်လည်စစ်ဆေး အတည်ပြုတာတွေကို လုပ်ဆောင်ပြီးမှ ဆက်လက် အသုံးပြုခွင့်ပေးပါတယ်။

(၄) သံသယဖြစ်စရာ အသုံးပြုမှုတွေထဲက သတ်မှတ်ထားတဲ့ အချို့လုပ်ဆောင်ချက် activity တွေကိုတော့ သက်ဆိုင်ရာ အာဏာပိုင် အဖွဲ့အစည်းတွေ၊ regulators တွေဆီကို လိုအပ်သလို သတင်းပို့ပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ day 32 အတွက် ဖြစ်ပါတယ်။ Payments အကြောင်း၊ payment system တွေအကြောင်းကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

https://payzillion.com/
https://www.facebook.com/PayZillion/

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 33 - Fraud တွေကို ဘယ်လို ကာကွယ်ကြသလဲ

ငွေကြေးဝန်ဆောင်မှုတွေကို ခွင့်မပြုထားတဲ့ နည်းလမ်းတွေနဲ့ ရယူသုံးစွဲဖို့ ကြိုးစားတာဟာ fraud ဖြစ်ပါတယ်။ Fraud တွေဘာလို့ဖြစ်သလဲဆိုရင် payment provider တွေ၊ merchant တွေရဲ့ configuration နဲ့ operation ပိုင်းဆိုင်ရာ လိုအပ်ချက်ကြောင့်ဖြစ်စေ၊ regulator တွေ၊ သက်ဆိုင်ရာ အာဏာပိုင်အဖွဲ့အစည်းတွေရဲ့ ထိန်းကျောင်းမှုဆိုင်ရာ အားနည်းချက်ကြောင့်ဖြစ်စေ၊ အသုံးပြုသူ end-user တွေမှာ လုံခြုံရေးဆိုင်ရာအသိပညာ security awareness မရှိတာကြောင့်ဖြစ်စေ ဖြစ်နိုင်ပါတယ်။ Fraud တွေကို ထိန်းချုပ်ဖို့အတွက် ယေဘုယျအားဖြင့် လုပ်ဆောင်ကြတာတွေကတော့

(၁) အကောင့် login ဝင်တာတွေ၊ device အပြောင်းအလဲ လုပ်တာတွေကို အကောင့်ပိုင်ရှင်ကလွဲပြီး မပြုလုပ်နိုင်အောင် စစ်ဆေးအတည်ပြုတာ၊ သံသယဖြစ်စရာရှိမရှိ စောင့်ကြည့်တာတွေ လုပ်ပါတယ်။

(၂) အသုံးပြုရာမှာ PIN, OTP, biometric စစ်ဆေးမှုတွေ၊ multi factor authentication (MFA) တွေနဲ့ အကောင့်ပိုင်ရှင်၊ ကတ်ပိုင်ရှင် အစစ်ဖြစ်ကြောင်း အတည်ပြုပါတယ်။

(၃) ခိုးယူအသုံးပြုခံရတဲ့အခါ လက်ကျန်ငွေ balance ရှိသမျှ အကုန်မသုံးနိုင်အောင် daily limit, weekly limit, monthly limit တွေ၊ per transaction limit တွေနဲ့ ဆုံးရှုံးနိုင်ခြေကို လျှော့ချပါတယ်။

(၄) ပုံမှန်မဟုတ်တဲ့ သုံးစွဲမှုပုံစံတွေကို real-time ဖြစ်စေ၊ near real-time ဖြစ်စေ စောင့်ကြည့်ပြီး အသုံးပြုမှုကို ငြင်းပယ်တာ၊ ဆိုင်းငံတာ၊ review လုပ်ပြီးမှ ပြန်လည်အသုံးပြုခွင့်ပေးတာတွေ လုပ်ပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ day 33 အတွက် ဖြစ်ပါတယ်။ Payments အကြောင်း၊ payment system တွေအကြောင်းကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

https://payzillion.com/
https://www.facebook.com/PayZillion/

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices

Day 34 - Payment Disputes များအကြောင်း

ငွေပေးချေသူ customer တွေနဲ့ ရောင်းချသူ merchant တွေကြား transaction နဲ့ ပတ်သတ်ပြီး အငြင်းပွားမှု case တွေဖြစ်တာဟာ dispute ဖြစ်ပါတယ်။ ကတ်နဲ့လား၊ wallet တွေ mobile payment တွေနဲ့လား၊ QR နဲ့ငွေပေးချေတာလား၊ peer to peer ငွေပေးချေတာလား၊ closed-loop payment ပုံစံနဲ့ ငွေချေတာလား opened-loop payment ပုံစံနဲ့လား အစရှိသဖြင့် မတူညီတဲ့ ငွေပေးချေမှု ပုံစံအလိုက် ကိုင်တွယ်ဖြေရှင်းပုံတွေ ကွာခြားမှုရှိမှာ ဖြစ်ပါတယ်။

အငြင်းပွားမှု dispute case တွေ ရှိလာတဲ့အခါ ငွေပေးချေသူ customer တွေအနေနဲ့ အရင်ဆုံး merchant ကို ဆက်သွယ်ပြီး အဆင်မပြေမှုကို ဖြေရှင်းတာက အမြန်ဆုံးနဲ့ အကောင်းဆုံး ဖြေရှင်းနည်း ဖြစ်ပါတယ်။ ကိုယ်ဝယ်ယူထားတဲ့ ဝန်ဆောင်မှုကို အပြည့်အဝ ရမရနဲ့ ရောင်းချထားတဲ့ ပစ္စည်းကို မှန်ကန်စွာ ဝန်ဆောင်မှု ပေးထားမထားကို customer နဲ့ merchant ကသာ သိနိုင်တာမို့ ဖြစ်ပါတယ်။

Customer နဲ့ merchant ကြား ဖြေရှင်းလို့ အဆင်မပြေခဲ့ရင်တော့ ကတ်အသုံးပြု ငွေပေးချေမှုတွေမှာဆိုရင် issuer ဆီကနေတစ်ဆင့် ဆက်လက်ဖြေရှင်းရမှာပါ။ Wallet တွေ၊ QR တွေနဲ့ mobile အသုံးပြု ငွေပေးချေမှုတွေမှာလည်း ကိုယ်ဘယ် mobile payment app ကို အသုံးပြုပြီး ငွေပေးချေသလဲပေါ်မူတည်ပြီး အဲ့ဒီ app ရဲ့ provider ကနေ တစ်ဆင့် ဖြေရှင်းရမှာ ဖြစ်ပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ day 34 အတွက် ဖြစ်ပါတယ်။ Payments အကြောင်း၊ payment system တွေအကြောင်းကို လက်တွေ့ကျကျ တိုတိုရှင်းရှင်းနဲ့ တစ်နေ့တစ်ပုဒ် ဆက်ပြီး တင်ပေးပါမယ်။)

https://payzillion.com/
https://www.facebook.com/PayZillion/

#40DaysOfPayments #PaymentsMadeSimple
#Payments #FinTech #DigitalPayments #FinancialServices