Redesign av konseptet Core Banking (Reghunathan Sukumara Pillai)

Da Core Banking-løsningen (CBS) ble designet på slutten av 1990-tallet, ble den konstruert for å koble til de forskjellige filialene til banken ved hjelp av en sentral database og sikre riktig regnskap for å generere hovedboken. Den fjernet de enorme hovedbøkene i banken
hvor manuell bokføring ble utført av personalet og eliminerte den filialbaserte regnskapsprogramvaren (Total filialautomatiseringsprogramvare) som hjalp resepsjonen/tellerne med å utføre rutinemessige/gjentatte transaksjoner. De første leverandørene av programvaren fungerte /co-build
programvaren med store banker som ga kravene til å konvertere den manuelle hovedbokoperasjonen til en regnskapsprogramvare. Mens intensjonen var å utføre online sanntidsregnskap, var noen av prosessene som førte til dette regnskapet også innebygd
som en del av CBS-pakken. Fokuset på designet var sentrert rundt de forskjellige forretningslinjene som var utbredt i bankene på det tidspunktet - CASA og gjeld, eiendeler og handel/valuta - først og fremst fra et regnskapsperspektiv.

Fra et konseptperspektiv lyktes det i å eliminere den manuelle regnskapsføringen, forbedret transparens i rapportering fra et Bank/regulatorisk perspektiv og bistått kunden i bankvirksomhet hvor som helst når som helst, siden alle kontoer er knyttet til en sentralisert database.
Banker hvis ansatte brukte mer tid på avstemming, manuell rentepostering og manuell oppretting av hovedbok, dro et lettelsens sukk der feil ble minimert, data tilgjengelig i en programvare i stedet for reskontro, rapportering var jevnere. Fra en kunde
perspektiv, passbøker og kontoutskrifter ble gitt på en automatisert måte, saldoinformasjon og uttak var mulig gjennom en minibank hvor som helst i samme by hvor kontoen ble åpnet/utenfor, med et grensesnitt til Core Banking-løsning (CBS), 
og dermed øke tilliten til bankøkosystemet.
Fra et bankperspektiv kan mange av virksomhetene flyttes fra filialbank til sentralisert celle, noe som gjør det mulig for frontkontorpersonalet å fokusere på kundeservice og kryssalg/forretningsforbedringer. Konseptet front office/back office oppsto hvor
et eget sett med team fokusert på back-end aktiviteter-, produktskaping og innovasjon, clearing, låneoperasjoner, handelsoperasjoner, kontoåpning, revisjon, avstemming, rapportering og MIS etc. Med mer informasjon og data på backoffice, banet det
veien for nye produktinnovasjoner som resulterer i lansering av flere produkter, og dermed øke virksomheten/fortjenesten for bankene. CBS hjalp banken med å globalisere/lokalisere produkter som er egnet for formålet for kunden, noe som gir kunden glede. 
Et tiår senere ble det innsett av bankene at CBS ikke er i stand til å imøtekomme forretningsområdene der flere prosesser/regler kreves for f.eks. betalinger og handelsoperasjoner. Mens CBS var i stand til å utføre regnskapet, var det ikke i stand til å bygge reglene/prosessene
kreves for forretningsdriften - for eksempel betalingsregler basert på kunde, beløp, tid, nettverk, gebyrer osv. Mens de konvensjonelle bankene som tok i bruk CBS fortsetter å operere/arbeide med programvaren for regnskap og holde reglene/prosessene for
betalinger/handel utenfor, kjøpte få av bankene spesialisert programvare for disse virksomhetene som typisk kunne imøtekomme disse prosessene og grensesnitt med CBS for regnskap. Den spesialiserte programvaren ble designet for å utføre prosessene/trinnene/reglene/unntakene
og livssyklusaktiviteter for den spesifikke virksomheten som til slutt kan kulminere i et regnskap. Mens betalinger til å begynne med flyttet utenfor kjernen, fulgte handels- og utlånsoperasjoner den samme veien for disse bankene, uten å legge bort CASA, gjeld og regnskap
innen CBS.
Fra begynnelsen av det siste tiåret dukket det opp et sett med nye virksomheter som inkluderte private banktjenester, kontanthåndtering, mikrolån, distribusjonsprodukter og ble populær hos bankene på grunn av synligheten for nye forretningsveier. Dette var heller
tvunget gjennom reguleringer eller på grunn av markedsfaktorer, og bankene begynte å være avhengige av nye programvareløsninger som reduserte avhengigheten ytterligere av kjernebankvirksomhet. Tiden så også fremveksten av digitale og selvbetjente kanaler hvor Millennials/new age-kunder
avhengig av nettleser/smarttelefon for å utføre banktransaksjoner. Selv om den eldre generasjonen kunder var litt motvillige, beveget de seg mot disse digitale kanalene for begrensede transaksjoner over en periode. Et jevnt og enkelt grensesnitt med CBS var nødvendig
som resulterte i at CBS-leverandører ble tvunget til å bygge disse API-ene/smarte grensesnittene. Dette sikret også at flere sikkerhets- og samsvarsprotokoller må bygges inn i applikasjonen for å redusere svindel for transaksjoner som har opphav utenfor CBS. Kundeopplevelser
, endret kundeatferd og kundebehov for bankvirksomhet drastisk i løpet av dette tiåret.  
Med fremveksten av Covid 19 ble antallet kundebesøk i bankens filialer ytterligere redusert globalt, og flere og flere transaksjoner ble utført digitalt, noe som skapte en stor belastning på CBS-programvaren. De digitale transaksjonene økte mangfoldig
under Covid-tiden takket være forskrifter, digitale alternativer tilgjengelig for kunder, e-handel og online betalingsalternativer, og det tvungne behovet for forbrukeren å handle med Covid-restriksjoner.
For å konkludere, redesign og modernisering av kjernebank er en prioritet i det nåværende tiåret med stadige endringer og med tanke på mange faktorer ved banktransaksjoner som flyttet fra filialer til mobil til sosiale medier til alternative kanaler. Den må bevege seg
bort fra regnskapsbasert CBS til regel/prosess basert med regnskap innebygd. Mens den opprinnelige utformingen først og fremst var fokusert på regnskap, må reglene/prosessene/unntakene for produktets/kontoens livssyklus på ulike stadier tas i betraktning for å møte behovene
i moderne tid. Brukeropplevelse var ikke en faktor som en del av den første utformingen som resulterte i redusert bruk av programvaren og med prosess/regler/trinn må brukeropplevelsen skrives om. Fra en menyvalgsdrevet tilnærming, prosessbasert tilnærming
for å informere brukeren om oppgavene som skal utføres/som skal utføres/neste trinn etc. må være tilgjengelig i dashbordet basert på tilgangsrettigheter, regler og privilegier til brukeren. Med økende digitale behov trenger relevante API-er som er basert på industriprotokoller
å være tilgjengelig for å oppfylle relevante forretningslivssyklusaktiviteter slik at transaksjoner kan utføres digitalt når som helst hvor som helst. Frakobling av flere forretningslinjer - forpliktelser, handel, betalinger, utlån, kontanthåndtering og uavhengig selvbetjening
funksjoner for flere områder innenfor gjeldende kjerne for prissetting/regnskap/master må vurderes mens programvaren redesignes. Avhengighet av begrensede databaser og plattform i henhold til den første byggingen må forbedres og modernisere kjernen med
muliggjøring av arbeid med alle plattformer eller databaser må være aktivert. Modernisering av kodebasene for å gjøre den oppdatert/tidsriktig med nye programmeringsspråk slik at det ikke er begrensninger for fremtidige endringer for konvertering med kodekonverterere/verktøy har
som skal følges. Med økende arbeidsbelastning i kjernen, og sannsynligvis vil bli testet videre, på grunn av digitalt momentum, må CBS aktiveres for å møte økte volumer og skala. CBS må overholde globale sikkerhetssamsvar og standarder. Versjonen
oppgraderinger, installasjoner og endringer må være jevne, akkurat som en automatisk patchoppdatering i en mobiltelefon, bortsett fra der det kreves store endringer og en oppløfting en gang i løpet av et tiår eller så. Mens den første CBS var i stand til å levere funksjonalitet/kode uten
ved å analysere sluttbruken, må den nye CBS ta en reimage tilnærming med sluttbrukeren i tankene. Fra en nettbasert transaksjonsbehandlingsplattform bør den forstå riket av online analyse for å gi meningsfull innsikt ved transaksjonens opprinnelsespunkt/behandling
syklus.
Det er flere CBS-programvare som er testet, utprøvd ved hjelp av funksjonalitet, vellykket i utvalgte markeder og mange nye CBS som har blitt beskåret i den siste tiden utelukkende basert på ny teknologi, regler, APIer og ennå ikke bevise deres legitimasjon. CBS
må holde seg oppdatert med markedskravene og nyere innovasjoner og teknologiløft i bank/finanssektoren og en ny tidsalder kjerne som er fleksibel og smidig må utformes som kan åpne seg for å imøtekomme økosystemaktørene
og tjenester og tilby helhetlig løsning til banker. Med skiftende banklandskap, må CBS redesignes med tanke på flere faktorer, og en slik programvare kan bli vellykket i det neste tiåret, ellers vil bankene utforske alternative hovedboksystemer, prosesser
/regelsystemer, API-systemer og bygg teknologien /applikasjonen egnet for deres bankbehov fra bunnen av ved å kombinere de ovennevnte systemene med/uten en CBS-programvare.