Finansinių paslaugų vartotojas paprastai nemato, kaip organizuota mokėjimo sistema ar kur saugomi jos duomenys. Jis pastebi rezultatą: ar pavyko prisijungti, ar pervedimas pasiekė gavėją, ar kilus klausimui gavo aiškų atsakymą. Todėl technologijų pasirinkimai fintech įmonėje lemia daugiau nei programėlės patogumą. Nuo jų priklauso paslaugos savikaina, plėtros galimybės ir gebėjimas laikytis klientui duotų pažadų.
Aktualios fintech technologijų tendencijos padeda suprasti galimus pokyčius, tačiau sprendimą turi pagrįsti konkreti problema. Įmonei, kurios klientai laukia dokumentų patikros, gali būti svarbesnis tvarkingas duomenų srautas nei nauja funkcija. Technologija tampa strategine dalimi tada, kai aišku, kokį verslo rezultatą ji turėtų pagerinti ir kokią papildomą riziką atneša.
Skaitmeninių mokėjimų kokybę lemia ir klientui nematomi sistemos sprendimai. Nuotrauka Towfiqu barbhuiya.
Technologijų komandą įtraukti prieš priimant sprendimą
Tarkime, fintech įmonė planuoja aptarnauti daugiau smulkiųjų verslų. Komercinė komanda mato paklausą, tačiau technologijų specialistai pastebi, kad esama sistema sunkiai apdoroja masinius mokėjimus. Jei jie įtraukiami tik po pažado klientams, tenka skubiai keisti sistemą ir derėtis dėl terminų. Dalyvaudami planavimo pradžioje, jie gali pasiūlyti siauresnį paslaugos startą, saugų apkrovos bandymą arba kitą funkcijų įgyvendinimo seką.
Produkto komanda apibrėžia vartotojo poreikį, finansų specialistai vertina sąnaudas, rizikos ir atitikties komandos nustato apribojimus, o technologijų komanda paaiškina priklausomybes ir galimus gedimus. Sprendimas turi apimti ir funkcijos priežiūrą: stebėseną, atnaujinimus, pagalbą klientams bei tiekėjų pakeitimus.
Baselio bankų priežiūros komitetas, pristatydamas finansų skaitmenizacijos ataskaitą, išskiria ir naujų technologijų naudą, ir jų kuriamas bei stiprinamas rizikas. Veiksmingas valdymas, darbuotojų gebėjimai ir rizikos kontrolė lieka esminiai. Tai padeda paaiškinti, kodėl technologijų biudžeto nepakanka vertinti vien pagal įdiegtų funkcijų skaičių.
|
Technologinis sprendimas |
Strateginis klausimas |
Naudingas vertinimo rodiklis |
|---|---|---|
|
Procesų automatizavimas |
Kur klientas ar darbuotojas praranda laiką? |
Rankinių veiksmų skaičius vienam atvejui |
|
API integracija |
Kokią paslaugą galime suteikti per partnerį? |
Integracijos sutrikimai ir jų poveikis |
|
Debesijos paslaugos |
Kaip aptarnausime augančią apkrovą? |
Sąnaudos vienai sėkmingai operacijai |
|
DI modelis |
Kokį sprendimą verta padėti priimti? |
Klaidingi rezultatai ir peržiūros poreikis |
API atveria paslaugas ir sukuria priklausomybes
API, arba programų sąsaja, yra sutartas būdas dviem sistemoms apsikeisti užklausomis ir atsakymais. Pavyzdžiui, apskaitos programa gali perduoti mokėjimo duomenis finansinių paslaugų sistemai ir vėliau gauti jo būseną. Taip darbuotojui nereikia tų pačių duomenų dar kartą suvesti rankomis. Sąsaja apibrėžia, kokie duomenys priimami, kas turi teisę juos perduoti ir kaip pranešama apie klaidą.
Strategiškai tai leidžia teikti paslaugą ten, kur klientas jau dirba. Tačiau integracija nėra baigta vien todėl, kad pavyko išsiųsti bandomąją užklausą. Reikia susitarti dėl sąsajos pakeitimų, prieigos teisių, užklausų ribojimo ir veiksmų, kai partneris neatsako. Vienai užduočiai skirtai integracijai neturėtų būti suteikiama platesnė prieiga prie klientų duomenų, nei jai būtina.
Standartinę funkciją kartais prasminga įsigyti, o specifinį darbo procesą kurti patiems. Vis dėlto partnerio pajėgumai, sutarties sąlygos ir pagalbos prieinamumas tampa įmonės paslaugos kokybės dalimi. Kiekvienai svarbiai integracijai reikia atsakingo žmogaus, o ne vien techninės dokumentacijos.
Automatizavimą atskirti nuo dirbtinio intelekto
Automatizavimas gali veikti pagal aiškias taisykles, visai nenaudodamas dirbtinio intelekto. Sistema gali patikrinti privalomus laukus, sugretinti sąskaitos įrašus arba perduoti užduotį kitam darbuotojui. Pirmiausia verta pašalinti dubliuojamą darbą ir sutvarkyti duomenis, užuot sudėtingu modeliu mėginus kompensuoti netvarką.
DI praverčia ten, kur reikia atpažinti dėsningumus ar apdoroti nevienodai pateiktą informaciją. Hipotetinis klientų aptarnavimo modelis galėtų parengti atsakymo projektą pagal patvirtintus dokumentus. Tačiau jis gali neteisingai suprasti klausimą, remtis pasenusia informacija arba pateikti įtikinamai skambantį neteisingą atsakymą. Todėl jo naudą reikia lyginti su patikrintu paprastesniu procesu.
JAV Nacionalinio standartų ir technologijų instituto (NIST) dirbtinio intelekto rizikos valdymo sistema skirta savanoriškai padėti organizacijoms įtraukti patikimumo vertinimą į DI kūrimą, naudojimą ir vertinimą. Tai nėra pažadas, kad pagal gaires sukurtas modelis neklys. Įmonė vis tiek turi apibrėžti jo naudojimo ribas ir tikrinti rezultatus.
Reikėtų nustatyti, kokius duomenis modelis naudoja, kuriuos atsakymus peržiūri žmogus ir kada automatizuotas veiksmas sustabdomas. Vertinant sukčiavimo požymius svarbu stebėti praleistus įtartinus atvejus ir nepagrįstai sustabdytas teisėtas operacijas. Peržiūrintis darbuotojas turi matyti kontekstą ir galėti pakeisti sprendimą. Formalus patvirtinimo mygtukas nesuteikia kontrolės, jei neskirta laiko įsigilinti.
Debesijos mastelį vertinti kartu su pasitraukimo galimybe
Debesijos paslaugos leidžia lanksčiau paskirstyti skaičiavimo išteklius. Pavyzdžiui, ataskaitų rengimo apkrova mėnesio pabaigoje gali padidėti, nors likusią mėnesio dalį tokio pajėgumo nereikia. Vis dėlto lankstumas turi kainą: duomenų saugojimas, perdavimas ir papildomos paslaugos gali pakeisti iš pradžių patrauklų sąnaudų skaičiavimą.
ECB bankų priežiūros pristatyme apie debesijos paslaugas aptariama priklausomybės nuo tiekėjo rizika ir pasitraukimo strategijų reikšmė. Taip pat pabrėžiama, kad už išorėje teikiamas paslaugas bankai išlaiko atsakomybę. Šis bankams skirtas požiūris naudingas ir svarstant fintech įmonės veiklos tęstinumą.
Prieš pasirenkant tiekėją verta patikrinti, kokiu formatu bus galima pasiimti duomenis, kokias sistemos dalis reikėtų perkurti ir kas atliktų perkėlimą. Vien atsarginė kopija dar neįrodo, kad paslaugą pavyks atkurti kitoje aplinkoje. Tam reikalingas bandymas, kuriame tikrinami duomenys, prieigos ir svarbiausių funkcijų veikimas.
Kelių tiekėjų naudojimas irgi nėra savaiminis atsparumo garantas: jis didina valdymo sudėtingumą. Sprendimą reikėtų sieti su paslaugos svarba, atkūrimo poreikiu ir komandos gebėjimais. Pasitraukimo sąnaudos turi būti įtrauktos į pasirinkimo vertinimą.
Komandos darbas ir aiškūs procesai padeda prižiūrėti technologinius sprendimus. Nuotrauka Marvin Meyer.
Mokėjimo greitis turi eiti kartu su aiškia būsena
ECB nurodo, kad momentiniais mokėjimais lėšos gavėjui tampa prieinamos per dešimt sekundžių, o paslauga veikia visą parą, kiekvieną metų dieną. Klientų operacijos nesustoja pasibaigus darbo dienai.
Patikimumo problemą gerai parodo hipotetinė situacija. Klientas patvirtina pervedimą, tačiau programėlė dėl ryšio sutrikimo negauna atsakymo. Paspaudęs dar kartą jis neturi netyčia sukurti antro mokėjimo. Tam naudojama idempotencija: ta pati operacija identifikuojama taip, kad pakartotinis jos pateikimas nesukeltų papildomo finansinio veiksmo. Būtina sutarti ir dėl identifikatoriaus galiojimo bei to, kaip sistema elgiasi gavusi prieštaringus duomenis.
Negautas atsakymas taip pat nėra įrodymas, kad mokėjimas nepavyko. Sistema turi patikrinti jo būseną, o klientui aiškiai parodyti, kada rezultatas dar tikslinamas. Operacijų įrašų sutikrinimas padeda aptikti neatitikimus tarp vidinės apskaitos ir partnerio pranešimų. Tai apsaugo nuo situacijos, kai gražiai atrodantis ekranas slepia neišspręstą finansinį įrašą.
Vadovybei verta stebėti neaiškios būsenos atvejus ir sutrikimų trukmę. Vien vidutinė atsakymo sparta neparodo, kiek klientų liko nežinioje.
Incidentas turi pakeisti ir sistemą, ir darbo tvarką
Skaitmeninės veiklos atsparumo aktas DORA taikomas nuo 2025 m. sausio 17 d. Europos Komisija išskiria informacinių ir ryšių technologijų rizikos valdymą, incidentų pranešimus ir atsparumo testavimą. Konkrečios pareigos siejamos su reglamento apimamais subjektais; vien fintech pavadinimas nepatvirtina, kad įmonei taikoma visa jo apimtis.
Svarbu iš anksto sutarti, kas vadovauja incidento valdymui. Technologijų komanda tiria sutrikimą ir atkuria veikimą, veiklos komanda vertina operacijų būseną, klientų aptarnavimas perduoda informaciją. Rizikos ir atitikties specialistai vertina pranešimų poreikį, o koordinatorius užtikrina, kad darbai nedubliuojami ir sprendimai užfiksuojami.
Po sutrikimo verta atkurti įvykių seką: kada problema prasidėjo, kas ją pastebėjo, kodėl stebėsena nesuveikė ir kokie veiksmai padėjo. Jei partnerio paslauga neatsakė, pamoka gali būti ne tik papildoma techninė apsauga, bet ir aiškesnis eskalavimo kontaktas. Kiekvienam taisomajam veiksmui reikia atsakingo žmogaus ir patikrinimo, ar pakeitimas išsprendė problemą.
Šios pamokos turi paveikti kitus sprendimus: funkcijos planuojamos kartu su priežiūros poreikiu, partnerių pasirinkimas apima veiklos tęstinumą, o DI diegimas apima klaidų peržiūrą. Taip investicijų kryptį lemia klientų patirtis ir gebėjimas patikimai teikti paslaugą.
Trumpi atsakymai į praktinius klausimus
Kada verta pradėti nuo nedidelio bandymo
Kai rezultatą galima patikrinti ribotoje aplinkoje. Iš anksto nustatykite sėkmės kriterijų ir sustabdymo sąlygą. Bandymas turi atsakyti į konkretų klausimą.
Ar technologijų vertę galima pamatuoti vien sutaupytu laiku
Vertinkite ir klaidų taisymo sąnaudas bei operacijų užbaigimą. Greitesnis procesas gali sukurti daugiau išimčių, kurias tenka spręsti rankomis.
Kaip nuspręsti, ką keisti pirmiausia
Pasirinkite dažną arba didelį poveikį turinčią problemą, kurios rezultatą galite išmatuoti. Palyginkite patobulinimą su esama padėtimi, tada plėskite sprendimą.
