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

Day 35 - Fraud Management အတွက် Risk Rules များ

Digital payment system တွေမှာ ငွေပေးချေမှုတွေ လုံခြုံမှုရှိစေဖို့ building blocks အနေနဲ့ အသုံးပြုလေ့ရှိတဲ့ risk rules တွေကတော့

(၁) Velocity Rules များ
သတ်မှတ်ထားတဲ့ အချိန်ကာလအတွင်းမှာ ငွေပေးချေမှု ပြုလုပ်တဲ့ အကြိမ်အရေအတွက်ကို check လုပ်တာ ဖြစ်ပါတယ်။
ဥပမာ။ ။ အသုံးပြုသူ တစ်ယောက်တည်းက ၁မိနစ်အတွင်း ၃ကြိမ်ထက်ပိုပြီး ငွေပေးချေမှု ပြုလုပ်ရင် reject လုပ်မယ်၊ ၁နာရီအတွင်း မတူညီတဲ့ ကတ်၅ကတ်နဲ့ ငွေပေးချေရင် block လုပ်မယ် အစရှိသဖြင့် အသုံးပြုတဲ့ အကြိမ်ရေ frequency အပေါ်မှာ မူတည်ပြီး ထိန်းချုပ်ပါတယ်။

(၂) Limit နဲ့ Threshold Rule များ
ငွေပေးချေမှု transaction တစ်ကြောင်းမှာ အများဆုံး အသုံးပြုနိုင်တဲ့ ငွေပမာဏ၊ daily, weekly, monthly မှာ အများဆုံး အသုံးပြုနိုင်တဲ့ ငွေပမာဏတွေကို ကန့်သတ်ထားတာပါ။
ဥပမာ။ ။ ငွေတစ်ခါလွှဲရင် ၃သိန်းထက် မကျော်ရ၊ တစ်နေ့လုံး စုစုပေါင်း ၁၀သိန်းထက် မကျော်ရ အစရှိသဖြင့် သတ်မှတ်ထားတာမျိုးပါ။ သတ်မှတ်ထားတဲ့ ငွေပမာဏထက် ပိုသုံးတဲ့အခါမှာ reject လုပ်မှာ ဖြစ်ပါတယ်။

(၃) List Based Rules များ
Blacklist, whitelist အစရှိသဖြင့် စာရင်းသွင်းထားပြီး transaction လုပ်တဲ့အခါတိုင်းမှာ တိုက်စစ်ပြီး reject သို့မဟုတ် approve လုပ်ပေးတာပါ။
ဥပမာ။ ။ Fraud ဖြစ်ဖူးတဲ့ သို့မဟုတ် ဖြစ်လေ့ရှိတဲ့ email တွေ၊ card BIN (ကတ်နံပါတ်ရဲ့ ထိပ်ဆုံး ၆လုံး/၈လုံး) တွေ အစရှိသဖြင့်ကို blacklist စာရင်းသွင်းထားပြီး ငွေပေးချေမှု ပြုလုပ်တိုင်းမှာ reject လုပ်တာ ဖြစ်ပါတယ်။

(၄) Location နဲ့ Attribute Rules များ
အသုံးပြုသူရဲ့ IP Address၊ နိုင်ငံ၊ merchant category code (MCC) အစရှိတာတွေ အပေါ်တူတည်ပြီး အသုံးပြုခွင့်ကို ကန့်သတ်တာ ဖြစ်ပါတယ်။
ဥပမာ။ ။ အီရန်နိုင်ငံကနေ ဝင်လာတဲ့ ငွေပေးချေမှု transaction အားလုံးကို reject လုပ်မယ်၊ လောင်းကစားနဲ့ ဆက်စပ်တဲ့ gambling merchant တွေ အသုံးပြုတဲ့ MCC code နဲ့ ဝင်လာသမျှ transaction အားလုံးကို reject လုပ်မယ် အစရှိသဖြင့် သတ်မှတ်ထားတာ ဖြစ်ပါတယ်။

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

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

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

Day 36 - Cardholder Data များ လုံခြုံမှုရှိစေဖို့ PCI DSS အကြောင်း

PCI DSS ကတော့ “Payment Card Industry Data Security Standard” ဖြစ်ပြီး၊ ကတ်အသုံးပြုသူတွေရဲ့ အချက်အလက်တွေ လုံခြုံမှုရှိစေဖို့ လိုအပ်တဲ့ PCI DSS requirement ၁၂-ချက် ရှိပါတယ်။

(၁) Firewall တွေ၊ network security control တွေ ထားရှိပြီး သေချာစွာ maintain လုပ်ပါ။

(၂) System နဲ့ device အားလုံးမှာ လုံခြုံတဲ့ configuration ကိုပဲ သုံးပါ။ Default ပါလာတဲ့ password အစရှိတာတွေကို ပြောင်းလဲအသုံးပြုပါ။

(၃) System ထဲမှာ သိမ်းဆည်းထားတဲ့ အချက်အလက်တွေကို လုံခြုံစွာထားပါ။ Encryption လုပ်တာတွေ၊ masking လုပ်တာတွေနဲ့ အလွယ်တကူ access မလုပ်နိုင်၊ မမြင်နိုင်အောင် ကာကွယ်ထားပါ။

(၄) Cardholder တွေရဲ့ အချက်အလက်တွေကို network ကနေ ပေးပို့တဲ့အခါမှာ strong cryptography ကို အသုံးပြုပြီး ပေးပို့ပါ။

(၅) System နဲ့ network တွေ အားလုံးကို virus တွေ၊ malware တွေ ရန်ကနေ ကာကွယ်ပါ။

(၆) System နဲ့ software တွေကို secure ဖြစ်အောင် develop လုပ်ပြီး၊ ပုံမှန် maintain လုပ်ပါ။

(၇) System နဲ့ cardholder ရဲ့ အချက်အလက်တွေကို လုပ်ငန်းလိုအပ်ချက်အရ တကယ်သိဖို့ လိုအပ်တဲ့လူကိုပဲ access လုပ်ခွင့်ပေးပါ။ လိုအပ်တဲ့ permission တွေပဲ access ပေးပါ။

(၈) System ကို access လုပ်မယ့် user တိုင်းကို ဘယ်သူဘယ်ဝါလဲဆိုတာ သေချာ identify လုပ်ပြီးမှ အသုံးပြုခွင့်ကို authenticate လုပ်ပါ။

(၉) Cardholder တွေရဲ့ အချက်အလက်တွေ ထားရှိတဲ့ server ခန်းတွေ၊ data center တွေကို လူတိုင်း ဝင်ထွက်လို့ မရအောင် physically ကန့်သတ်ထားပါ။

(၁၀) System နဲ့ cardholder ရဲ့ အချက်အလက်တွေကို access ဝင်ကြည့်တာ၊ သုံးတာ အားလုံးကို log မှတ်ထားပါ။ Monitor လုပ်ပါ။

(၁၁) System တွေနဲ့ network security တွေကို လုံခြုံမှု ရှိမရှိ ပုံမှန် စမ်းသပ်စစ်ဆေးပါ။

(၁၂) Information security နဲ့ ပတ်သက်ပြီး ဝန်ထမ်းတွေအားလုံး လိုက်နာရမယ့် စည်းမျဉ်းစည်းကမ်း policy တွေ၊ အစီအစဉ် program တွေ ချမှတ်ပြီး စဉ်ဆက်မပြတ် ပံ့ပိုးပါ။

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

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

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

Day 37 - Payment Orchestration နဲ့ Smart Routing အကြောင်း

Payment orchestration ဆိုတာ payment gateway တွေ၊ processor တွေနဲ့ acquirer ပေါင်းစုံကို universal adapter အနေနဲ့ တစ်နေရာတည်းမှာ စုစည်းချိတ်ဆက်ပေးထားတဲ့ နည်းပညာ ဖြစ်ပါတယ်။ သူ့ရဲ့ အရေးကြီး လုပ်ဆောင်ချက်တစ်ခုကတော့ smart routing လုပ်ပေးတာပါ။ Transaction တိုင်းကို provider တစ်ခုတည်းဆီ ပို့မယ့်အစား အခြေအနေပေါ်မူတည်ပြီး အကောင်းဆုံးဖြစ်မယ့် path ကို real-time ရွေးချယ်ပြီး transaction process လုပ်ပေးပါတယ်။ Payment orchestration ကြောင့်

(၁) ကုန်ကျစရိတ်ကို သက်သာပြီး cost optimization ဖြစ်စေပါတယ်။ Currency အမျိုးအစား၊ အသုံးပြုတဲ့ ကတ်အမျိုးအစား အစရှိသဖြင့် အချက်အလက်များ အပေါ်မူတည်ပြီး fee အသက်သာဆုံးဖြစ်မယ့် provider ဆီကနေ transaction ကို process လုပ်ပေးပါတယ်။

(၂) Transaction တွေကို approval ပိုမိုရရှိစေပြီး higher success rate ဖြစ်စေပါတယ်။ ဘယ် ငွေပေးချေမှုပုံစံ၊ ကတ်အမျိုးအစား အစရှိတာတွေကို ဘယ် acquirer ဆီက process လုပ်ရင် approval ပိုရသလဲအပေါ်မူတည်ပြီး transaction တွေကို process လုပ်ပေးပါတယ်။

(၃) ချိတ်ဆက်ထားတဲ့ provider တွေကြောင့် ဖြစ်ရတဲ့ ပြဿနာကို ကိုင်တွယ်ပေးပြီး failover protection လုပ်ပေးပါတယ်။ Provider A က အကြောင်းကြောင်းကြောင့် down သွားတဲ့အခါ transaction ကို provider B ဆီကနေ အလိုအလျောက် ပြောင်းလဲ process လုပ်ပေးပါတယ်။

Payment orchestration ဟာ နေ့စဉ် transaction အများကြီး process လုပ်ရတဲ့ လုပ်ငန်းကြီးတွေအတွက် အများကြီး အထောက်အကူ ဖြစ်စေပါတယ်။ အသေးစားလုပ်ငန်းတွေ အတွက်တော့ ရင်းနှီးရမယ့် ကုန်ကျစရိတ်နဲ့ နည်းပညာရှုပ်ထွေးမှုတွေကြောင့် မသင့်တော်ပါဘူး။

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

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

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

Day 38: Authorization Optimization အတွက် ပြင်ဆင်သင့်သည်များ

ငွေပေးချေမှု success rate တွေတက်လာစေဖို့နဲ့ failure rate တွေကို လျှော့ချနိုင်ဖို့အတွက် authorization optimization ကို လုပ်ကြပါတယ်။ ဒီနေရာမှာ technical ပိုင်းအရရော၊ human error တွေကိုရော စစ်ဆေးပြီး လိုအပ်ချက်တွေကို မှန်ကန်စွာ action ယူရမှာ ဖြစ်ပါတယ်။

(၁) Transaction တွေ decline ဖြစ်တဲ့အခါ တူညီတဲ့ pattern တစ်ခုခုရှိနေသလား သိအောင်လုပ်ပါ။ Failed ဖြစ်သွားတဲ့ အရေအတွက်ကိုပဲ ကြည့်တာထက် ဘယ်နိုင်ငံက၊ ဘယ် merchant ဆီက၊ ဘယ်ငွေပေးချေမှု wallet နဲ့ ကတ်အမျိုးအစားတွေက fail ဖြစ်နေတာလဲ၊ ဘယ်လို pattern မျိုးနဲ့ fail ဖြစ်နေသလဲဆိုတာကို ပုံမှန် စစ်ဆေးသင့်ပါတယ်။

(၂) Failed ဖြစ်ရတဲ့ transaction တိုင်းမှာ မတူညီတဲ့ failure reason code တွေရှိပါတယ်။ အဲ့ဒီ reason code တွေကို ခွဲခြားပြီးတော့ ကြည့်ရပါမယ်။ System error တွေ၊ technical error တွေကြောင့် failed ဖြစ်တာလား၊ insufficient balance လိုမျိုး အသုံးပြုသူရဲ့ လိုအပ်ချက်ကြောင့် failed ဖြစ်တာလား ခွဲခြားသိရပါမယ်။

(၃) Customer ကို ငွေပေးချေမှု နည်းလမ်းမျိုးစုံနဲ့ ပေးချေနိုင်အောင် စီစဉ်ထားပေးပါ။ ငွေပေးချေတဲ့အခါ ကတ်အမျိုးအစား တစ်မျိုးက failed ဖြစ်တဲ့အခါ၊ အခြား ကတ်တစ်ခုနဲ့ ပေးနိုင်တာမျိုး၊ wallet တွေ၊ mobile payment တွေနဲ့ ပြောင်းလဲပေးနိုင်တာမျိုးဖြစ်အောင် payment option တွေ ထည့်ပေးထားမယ်ဆို sale တွေကို မဆုံးရှုံးရတော့ဘူးပေါ့။

(၄) ငွေပေးချေရာမှာ ဝန်ဆောင်မှုပေးမယ့် payment system တွေကို ကိုင်တွယ်မယ့် ဝန်ထမ်းတွေကိုလည်း training သေချာပေးထားဖို့ လိုပါတယ်။ နည်းပညာအပေါ်ပဲ မှီခိုလို့ မရပါဘူး။ သက်ဆိုင်ရာ ဝန်ထမ်းတွေက system တွေကို သေချာနားလည်ပြီး ပြဿနာတွေကို troubleshoot လုပ်နိုင်ဖို့လိုပါတယ်။

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

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

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

Day 39 – Payment System ၏ KPI များ တိုင်းတာခြင်း

အခြားလုပ်ငန်းနယ်ပယ်တွေမှာလိုပဲ payment system တွေမှာလည်း Key Performance Indicator (KPI) တွေ အသုံးပြုပြီး performance တွေတိုင်းတာကြပါတယ်။ KPI ရလဒ်ပေါ်မူတည်ပြီး လိုအပ်တဲ့ technical enhancement တွေ၊ operational changes ပြုလုပ်ကြရပါတယ်။ အသုံးပြုသင့်တဲ့ KPIs တွေထဲက ၅ခုကို ဖော်ပြပေးလိုက်ပါတယ်။

(၁) ငွေပေးချေမှု အောင်မြင်မှုနှုန်း (Authorization Rate)
• တွက်နည်း။ ။ (Approved ဖြစ်တဲ့ Transaction ÷ စုစုပေါင်း Transaction) × ၁၀၀
• ဥပမာ - အကြိမ် ၁,၀၀၀ မှာ ၈၅၀ အောင်မြင်ရင် ၈၅% အောင်မြင်တာပေါ့။

(၂) စနစ်တည်ငြိမ်မှုနှုန်း (System Availability)
• တွက်နည်း။ ။ (System run/up ဖြစ်နေတဲ့ မိနစ် ÷ စုစုပေါင်း ကြာချိန် မိနစ်) × ၁၀၀
• ဥပမာ - ၄၃,၂၀၀ မိနစ် (၁လ) မှာ ၄၁,၇၆၀ မိနစ် run နိုင်ရင် uptime ၉၆.၆၇% ပေါ့။

(၃) Chargeback/Dispute တက်နှုန်း (Chargeback/Dispute Ratio)
• တွက်နည်း။ ။ (Chargeback အရေအတွက် ÷ Transaction စုစုပေါင်း) × ၁၀၀
• ဥပမာ - Transaction ၁၀,၀၀၀ မှာ chargeback အကြောင်း ၅၀ တက်ရင် ၀.၅% ပေါ့။

(၄) အမှန်တကယ်ရောင်းရနှုန်း (Sales Conversion Rate)
• တွက်နည်း။ ။ (ဝယ်ယူမှူ အောင်မြင်သူ စုစုပေါင်း ÷ Checkout page ရောက်လာသူ စုစုပေါင်း) × ၁၀၀
• ဥပမာ - လူ ၁,၀၀၀ checkout page ကိုရောက်လာပြီး လူ ၂၀၀ ဝယ်သွားရင် ၂၀% ပေါ့။

(၅) Fraud ဖြစ်ပွားမှုနှုန်း (Fraud Rate)
• တွက်နည်း။ ။ (Fraud ကြောင့် ဆုံးရှုံးငွေ စုစုပေါင်း ÷ ရောင်းရငွေ စုစုပေါင်း) × ၁၀၀
• ဥပမာ - သိန်းတစ်ရာဖိုး ရောင်းရပြီး ၁သိန်းဖိုး ဆုံးရှုံးမှုရှိရင် ၁% ပေါ့။

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

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

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

Day 40 - Payment System တွေ 99% Uptime ဖြစ်စေဖို့

Payment System တွေဟာ ငွေကြေးဝန်ဆောင်မှုနယ်ပယ် ဖြစ်တာကြောင့် 99.99% uptime ဖြစ်နေအောင် စီစဉ်ထားသင့်ပါတယ်။ ခဏတာ system outages ဖြစ်သွားခဲ့ရင်တောင် အသုံးပြုသူ customer တွေ၊ ချိတ်ဆက်ထားတဲ့ merchant တွေနဲ့ partner တွေအတွက် ကြီးမားတဲ့ ဆုံးရှုံးမှုတွေ ဖြစ်နိုင်ပါတယ်။ အဲ့ဒီအတွက် လုပ်ဆောင်လေ့ရှိတာတွေကတော့

(၁) System တွေ၊ server တွေ၊ network တွေနဲ့ transaction အခြေအနေတွေကို monitor လုပ် စောင့်ကြည့်ပါတယ်။ Dashboard တွေကနေ system တွေသာမက transaction အရေအတွက်တွေ၊ success rates တွေ၊ error codes တွေ၊ response times တွေ အစရှိသဖြင့် စောင့်ကြည့်ပြီး ပုံမှန်မဟုတ်ဘဲ အခြေအနေတွေကို ချက်ချင်း သိနိုင်အောင် စီစဉ်ထားကြပါတယ်။

(၂) Alerts တွေ၊ thresholds တွေ သတ်မှတ်ထားပြီး ထူးခြားတဲ့ အခြေအနေတွေမှာ ချက်ချင်း သိရအောင် လုပ်ပါတယ်။ System မှာ issuer တစ်ခုခုဖြစ်တာ၊ process တွေ ပုံမှန် အလုပ်မလုပ်တာ၊ decline တွေ အများကြီး တက်လာတာ အစရှိတဲ့ အခြေအနေတွေမှာ သက်ဆိုင်ရာ တာဝန်ရှိသူတွေဆီ alert တွေ auto ပို့ပေးနိုင်အောင် စီစဉ်ထားကြပါတယ်။

(၃) Backup system တွေ၊ server တွေ၊ network တွေ ထားရှိတာပါ။ အရေးကြီးတဲ့ system တိုင်းမှာ backups တွေ ရှိကြပါတယ်။ System တွေ၊ server တွေ၊ network တွေ ပုံမှန်အတိုင်း အလုပ်မလုပ်နိုင်တဲ့အခါနဲ့ maintenance လုပ်တဲ့အခါတွေမှာ backups system, server, network တွေ အသုံးပြုပြီးတော့ operation ကို ပုံမှန်အတိုင်း ဆက်လက်လုပ်ဆောင်နိုင်စေပါတယ်။

(၄) သက်ဆိုင်ရာ system တွေ၊ server တွေ၊ network တွေကို ပုံမှန် စစ်ဆေးမှု health checks တွေ လုပ်ပါတယ်။ စစ်ဆေးမှုတွေကြောင့် လက်ရှိဖြစ်နေတဲ့ issue တွေ၊ မကြာခင်မှာ ဖြစ်လာနိုင်တဲ့ issue တွေသာမက maintenance လိုအပ်နေတဲ့ အခြေအနေတွေကိုပါ စောစောစီးစီး သိရပြီး ပြဿနာမဖြစ်ခင် ကြိုတင်ဖြေရှင်းနိုင်စေပါတယ်။

(40-day “Payments Made Simple” series ရဲ့ Day 40 နောက်ဆုံး post ဖြစ်ပါတယ်။ ဒီ series မှာ တိုတိုနဲ့ ဖတ်ရလွယ်ကူအောင် ရေးထားတာရယ်၊ မတူညီတဲ့ ငွေပေးချေမှုပုံစံတွေကို cover ဖြစ်အောင် ရေးထားတာရယ်ကြောင့် payment instrument တစ်ခုချင်းစီအလိုက် ကွာခြားချက်တွေတော့ ရှိပါလိမ့်မယ်။ ဒီ series လေးက အားလုံးအတွက် အသုံးဝင်မယ်လို့ မျှော်လင့်ပါတယ်။)

40-day “Payments Made Simple” series တစ်ခုလုံးကို website မှာလည်း တင်ပေးထားပါတယ်။
https://payzillion.com/
https://www.facebook.com/PayZillion/

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