Vyriausybės taupymo lakštų platinimo informacinės sistemos, įskaitant išmaniąją programėlę, sukūrimo ir diegimo paslaugos

Išanalizuota

Lietuvos Respublikos finansų ministerija

Rinkos konsultacijaCPV: 72230000 - Vartotojų programinės įrangos kūrimo paslaugos

ID: 79784972026-05-21 09:56

Aprašymas

Perkančioji organizacija siekia sukurti ir įdiegti Vyriausybės taupymo lakštų platinimo informacinę sistemą (VTL IS) su išmaniąja programėle. Ši sistema bus skirta fiziniams asmenims nuotoliniu būdu įsigyti, valdyti ir išpirkti taupymo lakštus, užtikrinant saugų, patogų ir patikimą paslaugos teikimą bei integraciją su susijusiomis informacinėmis sistemomis. Taip pat bus užtikrinta garantinė priežiūra numatytam laikotarpiui.

Kvalifikaciniai reikalavimai

1Tiekėjas per pastaruosius 3 (trejus) metus (skaičiuojant nuo paskutinės pasiūlymų pateikimo termino pabaigos) arba per laiką nuo Tiekėjo įregistravimo dienos (jeigu Tiekėjas vykdo veiklą mažiau nei 3 (tris) metus), tinkamai sukūrė ir/ar atnaujino ir/ar pertvarkė elektroninių sandorių informacinę sistemą, kurios vertė yra ne mažesnė kaip 247.000,00 Eur be PVM.
2Pasiūlymo pateikimo metu sukurta ir/ar atnaujinta ir/ar pertvarkyta elektroninių sandorių informacinė sistema prieinama ir naudojama išorinių naudotojų (gyventojų ir/ar verslo subjektų).
3Pasiūlymo pateikimo metu sukurta ir/ar atnaujinta ir/ar pertvarkyta elektroninių sandorių informacinė sistema, turinti bent 1 (vieną) integracinę sąsają su kita informacine sistema.
4Projekto vadovas turi tarptautiniu mastu pripažįstamą projektų valdymo kvalifikaciją (pvz., ComTIA Project+, PMI PMP, Prince2 arba lygiavertį sertifikatą).
5Projekto vadovas per paskutinius 3 (trejus) metus vadovavo bent 1 (vienam) informacinės sistemos (IS) sukūrimo ir/ar atnaujinimo ir/ar pertvarkymo projektui.
6Informacinės sistemos architektas turi tarptautiniu mastu pripažįstamą sistemų architekto kvalifikaciją (pvz., TOGAF arba lygiavertį sertifikatą).
7Informacinės sistemos architektas per pastaruosius 3 (trejus) metus projektavo architektūrą bent 1 (viename) projekte, kurio metu buvo sukurta ir (ar) atnaujinta ir (ar) pertvarkyta informacinė sistema (darbai baigti, sistema priduota eksploatacijai), ir kuriame atliko informacinės sistemos architektūros projektavimo darbus ir (ar) parengė informacinės sistemos architektūros reikalavimus (specifikaciją).
8Sistemų integravimo specialistas per pastaruosius 3 (trejus) metus vykdė informacinių sistemų integravimo veiklas bent 1 (viename) IT paslaugų kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo (modernizavimo) projekte, įgyvendinant integracines sąsajas.
9UX/UI projektavimo specialistas per paskutinius 3 (tris) metus dalyvavo ne mažiau kaip 1 (viename) IT paslaugų kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo (modernizavimo) projekte, kuriame atliko naudotojo patirties (UX) analizę ir tyrimus bei vartotojo sąsajos (UI) sprendinių projektavimą ir prototipų kūrimą.
10Informacinių sistemų testuotojas turi tarptautiniu lygiu pripažįstamą testuotojo kvalifikaciją (pvz., ISTQB Foundation Level arba lygiavertį sertifikatą).
11Informacinių sistemų testuotojas per pastaruosius 3 (trejus) metus bent 1 (viename) IT paslaugų diegimo ir (ar) kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo projekte vykdė informacinių sistemų testavimo veiklas (pvz., funkcinį, integracinį ir (ar) naudotojų priėmimo testavimą).
12IT saugos specialistas turi tarptautiniu mastu pripažįstamą IT saugos specialisto kvalifikaciją (pvz., CISM, CISSP arba lygiavertį sertifikatą).
13IT saugos specialistas per pastaruosius 3 (trejus) metus, bent 1 (viename) IT sistemų kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo projekte vykdė informacinių sistemų ir (ar) registro duomenų saugumo užtikrinimo veiklas.
14Analitikas turi tarptautiniu mastu pripažįstamą analitiko kvalifikaciją (pvz., OMG Certified Expert in BPM 2 Fundamental level, OMG-Certified UML Professional Intermediate arba lygiavertį sertifikatą).
15Analitikas per pastaruosius 3 (trejus) metus, bent 1 (viename) IT paslaugų kūrimo ir (ar) atnaujinimo ir (ar) pertvarkymo projekte vykdė projekto reikalavimų analizės, specifikavimo ir (ar) procesų analizės veiklas.
16Tiekėjas turi turėti veikiančią informacijos saugumo valdymo sistemą, atitinkančią ISO/IEC 27001 „Informacijos saugumas, kibernetinis saugumas ir privatumo apsauga. Informacijos saugumo valdymo sistemos. Reikalavimai.“ arba lygiaverčio informacijos saugumo valdymo sistemos standarto reikalavimus.

Techniniai reikalavimai

Mokymai

1Diegėjas turi sudaryti mokymų planą (tvarkaraštis, apimtis, įrankiai, medžiaga).
2Diegėjas turės parengti vidinių (IS administratorių, Veiklos administratorių ir Turinio tvarkytojų) ir išorinių naudotojų vadovus.
3Vadovai turi būti išsamūs, suprantami, suskirstyti pagal funkcines sritis, iliustruoti ekranvaizdžiais ir apimti visų laukų paaiškinimus.
4Diegėjas turės parengti vidinių naudotojų mokymų medžiagą (teorija, praktinės užduotys, vientisa struktūra, visi reikalingi duomenys).
5Mokymai turi būti vykdomi testinėje (TEST) ar kitoje specialiai mokymams parengtoje VTL IS aplinkoje.
6Vidinių naudotojų mokymai organizuojami atskiromis grupėmis, užtikrinant, kad naudotojai nebus mokomi funkcijomis, kuriomis nesinaudos.
7Apmokyti iki 10 Perkančiosios organizacijos darbuotojų (skirtingoms rolėms, ne trumpesni nei 2 val.) ir iki 4 IS administratorių (ne trumpesni nei 3 val.).
8Mokymai gali būti atliekami nuotoliniu būdu, įrašomi ir pasidalinami su dalyviais.
9Jei VTL IS funkcionalumas pasikeičia po mokymų, turi būti surengti papildomi mokymai, arba įtraukti į sekančius planuojamus mokymus.
10Pasikeitus funkcionalumui, turi būti atnaujinta mokymų medžiaga ir/ar vadovai.
11Mokymai turi būti vedami lietuvių kalba, Perkančiosios organizacijos darbo valandomis.
12Išoriniams naudotojams Diegėjas turi parengti informatyvų vaizdo įrašą apie VTL IS funkcionalumą.

Saugumas

1VTL IS turi būti projektuojamas ir kuriamas atsižvelgiant į Lietuvos Respublikos asmens duomenų teisinės apsaugos įstatymą ir BDAR reikalavimus, užtikrinant duomenų subjektų teises (susipažinti, ištaisyti, ištrinti, apriboti tvarkymą, būti informuotam, nesutikti, perkelti duomenis).
2VTL IS turi atitikti Kibernetinio saugumo reikalavimų apraše nustatytus reikalavimus, įskaitant apsaugą nuo neautentifikuotos prieigos, sesijos perėmimo, duomenų perėmimo, žalingo kodo įterpimo (Injection, XSS), žalingų bylų įkėlimo ir OWASP TOP 10 pažeidžiamumų.
3Slapti duomenys (slaptažodžiai, API raktai, šifravimo raktai) negali būti saugomi programos kode ar konfigūraciniuose failuose, turi būti naudojamas centralizuotas slaptų duomenų valdymo sprendimas (secrets vault).
4Turi būti apibrėžta ir įgyvendinta kriptografinių raktų, sertifikatų ir integracijų raktų rotacijos politika.
5Turi būti sukonfigūruotos ir taikomos saugumo antraštės (bent CSP, HSTS, X-Frame-Options), pagrįstos „deny-by-default“ principu.
6Turi būti taikomi „mažiausių privilegijų“ (least privilege) ir „būtina žinoti“ (need-to-know) principai visiems komponentams.
7Turi būti užtikrintas saugumo įvykių registravimas, perduodant juos į centralizuotą stebėsenos / SIEM sprendimą.
8Ryšiai turi būti šifruojami, taikant šiuolaikinius kriptografinius standartus; silpni protokolai ir šifrai turi būti išjungti.
9Po saugumo testavimo (penetration tests), Diegėjas turi pašalinti aukšto ir vidutinio prioriteto klaidas iki bandomosios eksploatacijos pradžios.
10Sistema turi užtikrinti saugų HTTPS ryšį (ne mažesnis nei TLSv1.3) ir anti-DDoS apsaugą naudojant interneto skydą (pvz., CloudFlare).
11VTL IS (ir API) turi būti taikoma aplikacinio lygmens apsauga (L7) naudojant WAF.
12Diegėjas turi numatyti pažeidžiamumų skanavimo įrankius (static code analysis), integruotus į CI/CD procesą.
13VTL IS klaidų apdorojimas turi būti projektuojamas pagal OWASP rekomendacijas.
14Turi būti realizuotos priemonės centralizuotam žurnalinių įrašų surinkimui iš visų komponentų, taikant užklausų trasavimo principus.
15VTL IS turi būti atliekamas naudotojų veiksmų auditavimas (kas, kada, kokius duomenis keitė/įterpė/pašalino).
16Žurnaliniuose įrašuose negali būti saugomi slaptažodžiai, sesijos ID ar kiti slapti duomenys.
17Žurnaliniai įrašai turi būti apsaugoti nuo modifikavimo ir trynimo (appendonly), su prieigos ribojimu pagal RBAC ir šifruojami saugojimo metu (AES256).
18Žurnaliniai įrašai turi būti saugomi ne trumpiau kaip 1 metus, incidentų žurnalai – 2 metus.
19Visi žurnaliniai įrašai turi turėti tikslias laiko žymas su laiko zona, sistema turi naudoti sinchronizuotą laiką (NTP).
20Žurnaliniai įrašai turi būti apsaugoti nuo klastojimo naudojant hash grandines ar skaitmeninius parašus.
21Sistema turi turėti apibrėžtą auditų ir žurnalinių įrašų valdymo strategiją, įskaitant saugojimo politiką, archyvavimą ir integraciją su SIEM (pvz., Splunk, ELK, Azure Sentinel).
22Jeigu sistemoje naudojamas dirbtinis intelektas, Diegėjas privalo pateikti AI modelio kortelę, aprašančią modelius ir jų atitiktį ES Dirbtinio intelekto aktui, bei aprašyti saugumo priemones.
23Sistema turi naudoti saugius sesijų identifikatorius (ne mažiau kaip 128 bitų entropija), saugomus tik HTTP-only ir Secure slapuke, neturi būti perduodami URL parametruose.
24Sesijos neaktyvumo laikas 5 min., maksimalus sesijos galiojimo laikas 8 valandos.
25Po sėkmingo prisijungimo turi būti sugeneruota nauja sesija, o po atsijungimo sesija nedelsiant sunaikinta serveryje.
26Sistema turi apsaugoti nuo sesijos perėmimo (IP, UserAgent pokyčio detekcija, vienalaikių prisijungimų ribojimas).
27Visi sesijos įvykiai turi būti registruojami įvykių žurnale.
28Sistema turi naudoti tik VIISP teikiamus autentifikavimo metodus, negali saugoti naudotojo autentifikavimo duomenų.
29Sistema turi riboti prisijungimo bandymus, po 5 nesėkmingų bandymų paskyra turi būti laikinai užblokuota (min. 15 min.).
30Sistema turi turėti IP-based ir user-based bruteforce apsaugą (rate limiting, CAPTCHA).
31IS Administratorius turi turėti galimybę blokuoti naudotojo paskyrą, su visų veiksmų registravimu.
32Administratoriams turi būti privalomas dviejų faktorių autentifikavimas (MFA).
33Visi API endpoint’ai turi būti apsaugoti autentifikavimo mechanizmu (API raktai, OAuth 2.0).
34Visi API prašymai turi turėti timestamp arba nonce, serveris turi atmesti prašymus, senesnius nei 5 minutės.
35API turi turėti rate limiting mechanizmą (pvz., max 10 užklausų per minutę vienam IP).
36Visi įeinantys duomenys turi būti validuojami pagal schemą (JSON schema), maksimalus payload dydis ribojamas (pvz., 1 MB).
37API turi būti apsaugota nuo SQL injekcijų, XXE, Command injection, Path traversal, naudojant tik paruoštas užklausas.
38API negali grąžinti stack trace ar vidinės serverio informacijos; klaidos turi būti generinės.
39Visi duomenys tarp kliento ir serverio turi būti perduodami naudojant TLS 1.3 arba naujesnę versiją, HTTP automatiškai nukreipiamas į HTTPS (HSTS).
40Visi jautrūs duomenys turi būti šifruojami diske naudojant AES-256 ar lygiavertį algoritmą, atsarginės kopijos taip pat šifruojamos, raktai saugomi atskirai.
41Slaptažodžiai turi būti saugomi naudojant bcrypt, Argon2 arba PBKDF2, su druskinimu ir iteravimu.
42Visi vidiniai ryšiai tarp mikroservisų turi būti šifruoti (mTLS), vidiniai API neprieinami iš išorės.
43Konfigūracijos failai negali būti saugomi viešai, turi būti prieinami tik serverio procesams ir IS Administratoriams, šifruojami, jei yra slapti duomenys.
44Produkcinėje aplinkoje turi būti išjungtas debug režimas, nenaudojami testiniai raktai ar naudotojai.
45Visi konfigūracijos pakeitimai turi būti registruojami žurnaliniuose įrašuose, atliekami per autorizuotą CI/CD procesą ir peržiūrimi (keturių akių principas).
46Visi TLS sertifikatai turi būti atnaujinami automatiškai arba su automatiniu priminimu, negalima naudoti savarankiškai pasirašytų sertifikatų produkcijoje.
47Sistema turi turėti mechanizmą, tikrinantį, ar konfigūracijos failai nebuvo pakeisti neautorizuotai.
48Sistema turi turėti mechanizmus saugumo incidentams aptikti realiu laiku (nesėkmingų prisijungimų šuoliai, įtartini API kvietimai).
49Diegėjas privalo atlikti statinę kodo analizę (SAST) prieš kiekvieną produkcinį diegimą, šalinant kritinius ir aukšto lygio pažeidžiamumus.
50Diegėjas privalo atlikti dinaminę aplikacijos saugumo analizę (DAST) neprodukcinėje aplinkoje, apimant bent OWASP Top 10 rizikas, šalinant kritinius ir aukšto lygio pažeidžiamumus.
51Kritiniai pažeidžiamumai turi būti pašalinti nedelsiant, aukšto lygio – prieš produkcinį diegimą.

Testavimas

1Testavimo tikslai: įsitikinti, kad įgyvendinti visi funkciniai/nefunkciniai reikalavimai, įvertinti atitikimą ir identifikuoti klaidas.
2Turi būti atlikti šių tipų testavimai: vidiniai, funkcionalumo, integraciniai, regresiniai, priėmimo, greitaveikos ir našumo, saugumo testai.
3Diegėjas turi parengti testavimo planą, apimantį vykdymo tvarką, dalyvių atsakomybes, grafiką ir priėmimo kriterijus.
4Diegėjas turi parengti testavimo scenarijus visiems funkciniams reikalavimams, apimančius korektiškų ir nekorektiškų duomenų įvedimą.
5Testavimas turi tikrinti ne tik funkcionalumą, bet ir nefunkcinius reikalavimus (informacijos pateikimas, kalbos klaidos, UI reakcija).
6Testavimo scenarijai negali būti vykdomi produkcinėje aplinkoje; ji negali būti naudojama testavimui, derinimui ar eksperimentams.
7Testavimo aplinkos turi būti apsaugotos ir neprieinamos iš išorės (tik per VPN), su atskirais API raktais, sertifikatais ir konfigūracijomis.
8Testavimo ir programavimo aplinkose negali būti naudojami realūs produkciniai duomenys; turi būti naudojami sintetiniai arba anonimizuoti/pseudonimizuoti duomenų rinkiniai.
9Vidinius testavimus Diegėjas atlieka nedalyvaujant Perkančiajai organizacijai, pateikiant ataskaitą ir neatitikimų sąrašą.
102/3 naudotojo sąsajos funkcionalumo testų turi būti automatizuoti (pvz., TestComplete, Selenium).
11Automatizuoti testai negali saugoti slaptažodžių ar API raktų, neturi keisti produkcinės aplinkos.
12Testavimo įrankiai (pvz., Postman, JMeter, Selenium) naudojami tik neprodukcinėse aplinkose.
13Testavimo žurnaliniai įrašai negali būti realių asmens duomenų ir turi būti saugomi atskirai, su automatiniu išvalymu.
14Priėmimo testavimas vykdomas stebint Perkančiosios organizacijos atstovams, Diegėjas demonstruoja funkcijų veikimą.

Greitaveika

1VTL IS greitaveika turi būti planuojama numatant 100 vienu metu dirbančių naudotojų, atliekančių atsitiktinį veiksmą kas 2 s.
2VTL IS paleidimas neturi viršyti 2 sekundžių naudojant vidutinio lygio kompiuterį ar mobilųjį įrenginį.
3Atsakas naršyklėje į naudotojo atliktą veiksmą neturi viršyti 1 s.
4Ataskaitų generavimas ir paketiniai darbai neturi viršyti 30 s.
5Ilgiau nei 5 s trunkančių užklausų atveju turi būti numatytas progreso indikatorių rodymas.
6Atliktas SQL užklausų analizės ir optimizavimo darbas (bent 80 % dažniausiai vykdomų užklausų).
7Minimalūs projektiniai rodikliai: ne mažiau kaip 100 vienalaikių naudotojų; ne mažiau kaip 5 sandoriai per minutę normaliu režimu; sistemos atsako laikas piko metu neturi viršyti 3 s. 95 % užklausų; neturi būti prarandami ar dubliuojami sandoriai esant maksimaliam apkrovos lygiui.
8VTL IS surinktų balų skaičius „PageSpeed Insights“ teste turi būti ne mažesnis kaip 70 balų iš 100 mobiliajai ir stacionariai versijoms.
9Turi būti galimybė naudoti naršyklės spartinimą (browser caching) statiniams failams.
10Svetainė turi palaikyti serverio pusės spartinimo (server caching) sprendimus.
11Diegėjui atlikus nepriklausomą greitaveikos testavimą ir radus neatitikimų, trūkumus turės pašalinti savo sąskaita.

Duomenų bazė

1VTL IS centralizuotai duomenų bazei turi būti parinkta brandi reliacinė DBVS, užtikrinanti transakcijų vientisumą, replikavimą/aukštą prieinamumą, atsarginių kopijų ir atstatymo scenarijus, audito ir prieigos kontrolės priemones.
2Pirmenybė teikiama Oracle DBVS, atsižvelgiant į Finansų ministerijos praktiką, esamas licencijas ir eksploatavimo aplinkos standartizavimą.
3Duomenų bazėje turi būti saugomi: VTL emisijų katalogas, kategorijos, naudotojai, sandoriai, sandorių krepšeliai, turinio valdymo objektai, failų saugyklos įrašai, auditų ir žurnaliniai įrašai.
4Visi duomenys pasiekiami tik per VTL IS Web API sluoksnį. Tiesioginė prieiga prie duomenų bazės iš išorinių sistemų ar integracijų nėra leidžiama.
5VTL IS Web API neveikiant, turi būti atsarginis kanalas – SFTP, naudojamas mokėjimų inicijavimo failams pain.001 ir sandoriams į VIKSVA perduoti.
6Informacija duomenų bazėje, įskaitant formuojamas ataskaitas, Turinio valdytojui skaitymo (read-only) režimu turi būti prieinama per aplikaciją.

Duomenų apsauga

1VTL IS gali gauti tik tuos duomenis, kuriuos VIISP perduoda pagal teisės aktus: vardą, pavardę, asmens kodą, adresą, autentifikavimo faktą. Šie duomenys, išskyrus adresą, negali būti keičiami naudotojo.
2VIISP atsakymų žetonai negali būti saugomi ilgiau nei būtina sesijai sukurti, draudžiama juos saugoti duomenų bazėje.
3Turi būti registruojami visi prisijungimo bandymai: data, laikas, IP adresas, autentifikacijos būdas, rezultatas.
4IP adresai turi būti saugomi tik tiek, kiek būtina saugumo incidentų tyrimui ir pagal teisės aktus.
5Registracijos metu renkami tik šie duomenys: el. pašto adresas, telefono numeris, VIISP perduoti duomenys (vardas, pavardė, asmens kodas), naudotojo pasirinkti nustatymai, nebent būtina teisės aktų vykdymui.
6Jei Klientas tampa nerezidentu, mokesčių administravimo tikslais renkami papildomi duomenys: gimimo data, gyvenamosios vietos adresas, mokesčių mokėtojo kodas arba asmens dokumento data ir numeris.
7Turi būti registruojami visi paskyros kūrimo veiksmai: data, laikas, IP adresas, rezultatas.
8Sistema, sudarant sandorį, tvarko tik tuos duomenis, kurie būtini sandorio vykdymui: Kliento identifikavimo/kontaktiniai duomenys, sandorio ID, emisijos ISIN kodas, pirkimo suma/vienetų skaičius, mokėjimo informacija/būsena, sandorio data/laikas, techniniai žurnalai, kiti duomenys mokesčių administravimui.
9Sistema netvarko ir nesaugo Kliento mokėjimo paslaugos tiekėjo prisijungimo duomenų.
10Sandorio duomenys turi būti saugomi 10 metų pagal teisės aktų reikalavimus, negali būti ištrinami Kliento prašymu ir turi būti šifruojami (perdavimo ir saugojimo metu).
11Sandorio duomenys turi būti prieinami tik Klientui (jo paties sandoriai) ir vidiniams naudotojams (pagal rolę), vidiniai naudotojai negali keisti sandorio duomenų, išskyrus Administravimo procedūrose numatytus veiksmus.
12Sistema privalo registruoti sandorio sudarymo/patvirtinimo/gavimo laikus, bandymus inicijuoti/vykdyti sandorius, Administratorių veiksmus, techninius duomenis. Žurnalai negali būti ištrinami naudotojo prašymu.
13Sistema turi apsaugoti nuo neteisėto sandorio inicijavimo, sesijos perėmimo, duomenų pakeitimo, mokėjimo paskirties/būsenos klastojimo, neautorizuoto Administratoriaus prieigos.
14Po sandorio patvirtinimo Klientas negali keisti sumos, vienetų skaičiaus, emisijos, mokėjimo paskirties.
15Sistema neturi reikalauti ir saugoti Kliento mokėjimo paslaugos tiekėjo prisijungimo ar autentifikavimo duomenų (pvz., Smart-ID kodų).
16Mokėjimai inicijuojami per licencijuotą MIPT, veikiantį pagal PSD2 reikalavimus; sistema pati nevykdo mokėjimo.
17Sistema negali saugoti ir matyti Kliento mokėjimo sąskaitų likučių ar kitų mokėjimo paslaugos tiekėjo duomenų, kurių MIPT neperduoda.
18Mokėjimo paskirtis turi būti sugeneruota automatiškai ir negali būti keičiama naudotojų.
19Klientas turi teisę susipažinti su savo sandorio duomenimis, išskyrus techninius ir vidinius sistemos žurnalus. Neturi teisės reikalauti ištrinti sandorio duomenų.
20Sistema gali perduoti duomenis tik šiems subjektams: MIPT (mokėjimo inicijavimui), Nasdaq CSD Lietuvos filialui (VTL registracijai), Valstybinėms institucijoms (teisės aktų nustatytais atvejais), IT paslaugų teikėjams (kaip duomenų tvarkytojams).
21Techniniai žurnalai (IP, įrenginys, naršyklė) saugomi 2 metus, webhook/callback žurnalai – 2 metus, klaidų žurnalai – 1 metus.
22Visi sandorio duomenys turi būti šifruojami tiek perdavimo metu (TLS 1.3+), tiek saugojimo metu.
23Techniniai žurnalai turi būti pseudonimizuoti, jei juose yra asmens duomenų.

Sandorių valdymas

1Sandorio kelias turi būti realizuotas vedlio principu, vizualiai rodant progresą.
2Sistema turi sugeneruoti unikalų sandorio identifikatorių (sandorio ID) mokėjimui.
3Sistema turi inicijuoti mokėjimą per mokėjimų inicijavimo paslaugų teikėją (MIPT) ir nukreipti Klientą į mokėjimo paslaugos teikėjo aplinką.
4Mokėjimo paskirtis, perduodama MIPT, turi būti sugeneruota automatiškai pagal sandorio ID ir negali būti keičiama.
5Sistema turi rodyti sandorio būseną (Neapmokėtas, Laukiama banko patvirtinimo, Apmokėtas, Atmestas, Nepavykęs, Atšauktas) ir automatiškai ją atnaujinti.
6Kiekvienas būsenos pasikeitimas turi būti registruojamas su laiko žyma, ankstesne ir nauja būsena bei šaltiniu.
7Mokėjimo inicijavimo operacijos ir callback sąsajos turi būti atsparios pakartotiniams pranešimams, siekiant išvengti dubliuotų sandorių.
8Klientas turi nurodyti savo vardu atidarytą mokėjimo sąskaitą IBAN formatu, kuri bus naudojama palūkanų ir išmokų mokėjimams. Laukui vykdoma IBAN struktūros validacija, įskaitant Mod 97 kontrolės algoritmo tikrinimą.
9Mokėtojo duomenys (vardas ir pavardė) turi sutapti su Kliento duomenimis.
10Sandoriui įgavus SETTLED būseną, suformuojama VTL pirkimo sutartis.
11Kliento sandoriai turi būti atvaizduojami lentelės forma, su galimybe ieškoti ir filtruoti pagal datą, sumą, būseną.
12Turi būti galimybė peržiūrėti pilną sandorio informaciją, įskaitant ID, datą, laiką, būseną ir mokėjimo sąskaitos numerį.
13Visi dokumentai, kuriuos Klientas gali parsisiųsti, bus galimi tik PDF formatu.
14Kliento turimų VTL emisijų likučiai turi būti atvaizduojami lentelės forma, su galimybe ieškoti ir filtruoti informaciją.
15VTL likučiai turi būti atvaizduojami ir vizualiai (skrituline diagrama ar pan.).
16Sistema turi galėti apskaičiuoti mokėtinas sumas priešlaikiniam išpirkimui, galutiniam išpirkimui ir palūkanų mokėjimams.
17Klientas turi turėti galimybę paskyroje pateikti prašymą priešlaikinio išpirkimo prašymą, nurodant emisiją ir sumą. Prašymas turi būti pasirašomas el. parašu ir patalpinamas Kliento paskyroje.
18Klientas gali atšaukti priešlaikinio išpirkimo prašymą iki nurodyto termino, patvirtinant el. parašu.
19Metams pasibaigus, Kliento paskyroje turi tapti prieinamomis metinės ataskaitos (pdf formatu) apie sudarytus sandorius, metų pabaigoje turėtus galiojančius sandorius, per ataskaitinį laikotarpį išmokėtas palūkanas ir grąžintas sumas.

Duomenų migravimas

1Duomenų migravimas bus atliekamas kaip konkrečios iteracijos veiklos.
2Visus migravimui reikalingus duomenis pateiks Perkančioji organizacija.
3Iki duomenų migravimo pradžios Diegėjas turi parengti Duomenų migravimo aprašą (apimtis, procedūra, transformacijos).
4Duomenų migravimas galimas tik suderinus aprašą ir nustačius konkrečias datas.
5Jeigu tikslinga, prieš realų duomenų migravimą bus galima atlikti bandomąjį duomenų migravimą į testinę (TEST) VTL IS aplinką.
6Po atlikto duomenų migravimo Diegėjas turi parengti Duomenų migravimo ataskaitą.

Sistemos stebėsena

1Turi būti realizuoti sistemos ir jos komponentų (serverių, aplikacijų, duomenų bazės) veikimo stebėsenos priemonės, leidžiančios vizualiai stebėti ir fiksuoti pagrindinius veikimo sutrikimus, našumo rodiklius ir technines klaidas.
2Stebėsenos sprendimais ir jų licencijomis turės pasirūpinti (jas pateikti) Diegėjas.

Papildomos paslaugos

1Perkančioji organizacija turi teisę užsakyti papildomų paslaugų iki 800 darbo valandų, pagal Paslaugų teikėjo pasiūlyme nurodytą valandinį įkainį.
2Papildomos paslaugos gali būti naudojamos šioje specifikacijoje nenurodytų funkcionalumų užsakymui.
3Paslaugų teikėjas įsipareigoja taikyti ne didesnį paslaugų teikimo įkainį, negu pasiūlyme.
4Papildomo funkcionalumo įgyvendinimo aprašymas ir realizavimo data nustatoma užsakyme, su galimybe prašyti detalizavimo.
5Trūkumo pašalinimo terminas, jei įgyvendinamas papildomas funkcionalumas – ne ilgesnis kaip 3 darbo dienos.
6Diegėjas, įgyvendinęs užsakymą, pateikia VTL IS pakeitimo failus, diegimo instrukciją, testavimo dokumentaciją, atnaujintą naudotojo vadovą, IS administratoriaus dokumentaciją ir patvirtinimą dėl nustatymų tinkamumo.
7Diegėjas ne rečiau kaip kiekvieną mėnesį pateikia naujausios versijos programinio kodo aprašymus ir išvesties tekstus (kaupiamuoju principu).

Problemų šalinimas

1Problemos skirstomos į kritines klaidas, klaidas ir netikslumus.
2Kritinė klaida – techninė, loginė, sintaksės, žmogiška ar duomenų klaida, sutrikdanti VTL IS veikimą/pasiekiamumą, kai negalima atlikti svarbiausių veiksmų.
3Klaida – techninė, loginė, sintaksės, žmogiška ar duomenų klaida, nesutrikdanti VTL IS veikimo/pasiekiamumo, bet neatitinkanti reikalavimų.
4Netikslumas – smulki techninė, loginė, sintaksės, žmogiška ar duomenų klaida, nesutrikdanti VTL IS veikimo/pasiekiamumo, bet neatitinkanti reikalavimų/gerosios praktikos.
5Problemos rūšį nusprendžia Perkančioji organizacija, keitimas galimas tik jai sutikus.
6Reakcijos laikas (7-18 val. darbo dienomis): kritinei klaidai – ne ilgiau kaip 30 min., klaidai – ne ilgiau kaip 2 val., netikslumui – ne ilgiau kaip 1 darbo diena.
7Problemos sprendimo trukmė: kritinei klaidai – ne ilgiau kaip 8 val., klaidai – ne ilgiau kaip 3 darbo dienos, netikslumui – ne ilgiau kaip 5 darbo dienos.

Bendrieji reikalavimai

1VTL IS turi būti realizuotas lietuvių kalba, su galimybe ateityje lengvai pridėti kitas kalbas.
2Interneto svetainės vietoje, kurioje galima pasirinkti informacijos interneto svetainėje pateikimo kalbą, reikia pateikti interneto naršyklės įskiepių, atliekančių automatinio teksto vertimo funkcijas į kitas kalbas, sąrašą.
3Išorės naudotojas bet kuriame Parduotuvės puslapyje turi turėti galimybę užsisakyti naujienlaiškį, su galimybe atsisakyti naujienlaiškių tiesiogiai laiške ir Kliento paskyroje.
4Turi būti realizuojama integracija su Google Analytics, naudojant Finansų ministerijos pateiktą paskyrą.
5Turi būti galimybė integruoti Google Tag Manager kodą į svetainę, užtikrinant IP adresų anonimizavimą ir nenaudojant reklaminių funkcijų.
6Išorės naudotojas turi turėti galimybę peržiūrėti ir pasirinkti slapukų nustatymus.
7VTL IS naudotojo sąsajos sprendimai turi būti patogūs ir intuityvūs, atitikti prieinamumo reikalavimus pagal WCAG 2.2 AA principus ir būti pritaikyti neįgaliesiems.

Integracinės sąsajos

1Išoriniams duomenų mainams skirtos Diegėjo paruoštos API sąsajos turi veikti REST pagrindu.
2Visi trečiųjų šalių komponentai, bibliotekos, paslaugos ir integracijos turi būti saugūs, palaikomi ir teisėtai naudojami, be žinomų kritinių saugumo pažeidžiamumų.
3Visos integracijos su išorinėmis sistemomis turi būti apsaugotos autentifikavimu ir šifravimu, negali atskleisti daugiau duomenų, nei būtina funkcijai atlikti.
4Duomenys gali būti perduodami trečiosioms šalims tik su Perkančiosios organizacijos leidimu ir šifravimu, trečiosios šalys negali naudoti duomenų kitais tikslais.
5Diegėjo ar trečiųjų šalių specialistams prieiga prie sistemos gali būti suteikiama tik su Perkančiosios organizacijos leidimu, laikina, ribota, su registravimu žurnaliniuose įrašuose.
6Diegėjas yra atsakingas už visų naudojamų trečiųjų šalių komponentų saugumą, stebėseną ir atnaujinimą.

Sistemos architektūra

1VTL IS turi būti projektuojamas ir kuriamas moduliniu principu.
2VTL IS turi užtikrinti sistemos funkcijų aukštą prieinamumą (high availability) su RTO ne ilgesniu kaip 2 valandos ir RPO ne ilgesniu kaip 15 minučių.
3Turi būti numatytas ir dokumentuotas Veiklos atstatymo po incidento (Disaster Recovery) scenarijus.
4Kritiniai VTL IS komponentai (aplikacijų serveriai, API sluoksnis, duomenų bazė) turi būti realizuoti taip, kad jų gedimas nesukeltų visiško sistemos neveikimo, su automatiniu paslaugos perjungimu (failover).
5Duomenų bazė turi būti realizuota naudojant replikacijos mechanizmą.
6Architektūra turi būti pritaikyta veikti Perkančiosios organizacijos virtualioje infrastruktūroje ir turi sudaryti galimybę perkelti sistemą į kitą duomenų centrą neatliekant esminio programinių komponentų perkūrimo.
7VTL IS turi būti projektuojamas ir kuriamas užtikrinant sistemos plečiamumą (scalability), t. y. sistemos pajėgumus turi būti galima didinti tiek horizontaliai, tiek vertikaliai nekeičiant programinio kodo.
8Visos API sąsajos turi būti apsaugotos autentifikavimu, autorizavimu ir šifravimu, su prieigos apribojimu pagal mažiausios būtinos prieigos principą.
9VTL IS architektūra turi užtikrinti duomenų segmentavimą tarp viešo turinio, naudotojų paskyrų, sandorių duomenų ir administravimo funkcijų.
10Programėlė turi būti realizuojama naudojant „cross-platform“ kūrimo karkasą (pvz., React Native, Flutter, .NET MAUI ar lygiavertį), užtikrinant vieningą kodo bazę, ilgalaikį palaikymą (ne trumpesnį kaip 5 metai) ir galimybę perduoti projektą kitam tiekėjui.

Sistemos pasiekiamumas

1VTL IS turi būti pasiekiama ne mažiau kaip 99,5% laiko.
2Planiniai VTL IS atnaujinimo darbai turi būti atliekami nuo 22:00 iki 7:00 Lietuvos laiku.
3Naudotojams turi būti pateikiami sisteminiai TVS priemonėmis konfigūruojami pranešimai apie atliekamus arba planuojamus priežiūros darbus.

Bandomoji eksploatacija

1Bandomoji eksploatacija turi būti vykdoma VTL IS produkcinėje (PROD) aplinkoje.
2Diegėjas turi parengti bandomosios eksploatacijos planą (vykdymo tvarka, atsakomybės, grafikas, priėmimo kriterijai).
3Suderintas klaidų, kritinių klaidų ir netikslumų registravimo būdas ir stebėjimo galimybės.
4Nustatytos problemos skirstomos į kritines klaidas, klaidas ir netikslumus.
5Bandomoji eksploatacija laikoma sėkmingai įgyvendinta, kai tenkinami priėmimo kriterijai.
6Pasibaigus bandomajai eksploatacijai, Diegėjas turi parengti ataskaitą (rastų ir išspręstų problemų suvestinė, įgyvendintos veiklos) ir Perdavimo gamybinei eksploatacijai aktą.

Garantinis aptarnavimas

1Diegėjas turi užtikrinti neatlygintiną įdiegtos programinės įrangos garantinę priežiūrą ne trumpesnį nei 12 mėnesių terminą nuo VTL IS pateikimo gamybinei eksploatacijai.
2Garantinė priežiūra taikoma VTL IS funkcionalumams, sukurtiems kūrimo ir papildomų paslaugų užsakymo metu, paslaugų teikimo metu sukurtai programinei įrangai, licencinės programinės įrangos konfigūracijai, integracijoms ir dokumentacijai.
3Diegėjas privalo registruoti VTL IS eksploatavimo sutrikimus Projekto valdymo aplinkoje.
4Garantinės priežiūros paslaugos apima kritinių klaidų, klaidų ar netikslumų registravimą, taisymą, testavimą, diegimą, dokumentacijos tikslinimą ir konsultacijas.
5Problemos sprendžiamos pagal Techninės specifikacijos skyrių „Reikalavimai problemų šalinimui“ nustatytą tvarką.
6Techninės dokumentacijos atnaujinimai turi būti atlikti per 5 darbo dienas po problemos išsprendimo.
7Kas mėnesį Diegėjas turi pateikti garantinės priežiūros paslaugų teikimo ataskaitą apie suteiktų konsultacijų skaičių ir išspręstas problemas.

Kliento paskyros valdymas

1Klientas turi turėti galimybę peržiūrėti savo paskyros informaciją: vardą, pavardę, asmens kodą, el. pašto adresą, telefono numerį, rezidentiškumo informaciją, mokėjimo duomenis (IBAN), asmens duomenų tvarkymo ir sutikimų nustatymus, aktyvių sandorių portfelį, likučius, sandorių istoriją, ataskaitas.
2Vardas, pavardė ir asmens kodas (iš VIISP) yra tik skaitomi (read-only) ir negali būti keičiami nei išorės naudotojo, nei Administratorių.
3Pakeitus informaciją apie rezidentiškumą į nerezidento statusą, automatiškai aktyvuojami ir privalomais tampa gimimo datos, gyvenamosios vietos adreso rezidavimo valstybėje ir mokesčių mokėtojo kodo laukai.
4Visi duomenų keitimo veiksmai turi būti registruojami (data, laikas, IP, senoji ir naujoji reikšmės).
5Klientas savo paskyroje turi matyti paskutinio prisijungimo istoriją (data, laikas, IP adresas).
6Klientas turi turėti galimybę pakeisti savo el. pašto adresą, reikalaujant naujo patvirtinimo (OTP arba nuoroda el. laiške).
7Klientas turi turėti galimybę pakeisti savo telefono numerį, užtikrinant tarptautinį formatą (E.164) ir skaičių įvedimą.
8Klientas turi turėti galimybę pakeisti savo piniginių lėšų sąskaitą (IBAN).
9Atsiskaitymo duomenys negali būti keičiami likus daugiau nei 2 darbo dienoms iki priešlaikinio ar galutinio išpirkimo dienos.
10Klientas turi turėti galimybę atsisiųsti VTL IS saugomų savo asmens duomenų kopiją (tik asmens duomenys, be finansinių/techninių žurnalų).
11Klientas gali ištrinti paskyrą, jei neturi aktyvių sandorių.
12Pakeitus informacinį pranešimą apie asmens duomenų tvarkymą, Klientui prisijungus turi būti pateikta nauja versija su privalomu susipažinimo patvirtinimu.
13Sutikimai (pvz., naujienlaiškiams) turi būti atskiri, dokumentuojami, lengvai atšaukiami per paskyros nustatymus, neprivalomi ir ne iš anksto pažymėti.
14Klientas turi turėti galimybę peržiūrėti, perskaityti ir ištrinti savo registruotas ir gautas žinutes lentelės formatu, surūšiuotas pagal datą, su vizualiu naujų žinučių išskyrimu.
15Klientas turi turėti galimybę registruoti naują žinutę, užpildant temą, VTL informaciją, aprašymą ir prisegant dokumentus (pdf, jpg, png).
16Klientas turi turėti galimybę pats užblokuoti savo paskyrą, su sustiprinta autentifikacija atblokavimui.
17Paskyros atkūrimas galimas tik jei paskyra buvo užblokuota, bet ne ištrinta.
18Paskyros ištrynimas negalimas, jei Klientas turi aktyvių sandorių arba duomenys privalo būti saugomi pagal teisės aktus.
19Paskyros ištrynimas reiškia Kliento profilio duomenų pašalinimą, o asmens duomenys anonimizuojami, sandorių duomenys išsaugomi apskaitos ir teisinių reikalavimų tikslais.

Naudotojo sąsaja (UI/UX)

1VTL IS turi būti konstruojamas reaguojančio dizaino principais (responsive web design), informacija automatiškai koreguojasi priklausomai nuo ekrano dydžio.
2VTL IS naudotojo sąsaja turi būti prieinama ir funkcionuoti be klaidų kompiuterio, planšetinio kompiuterio ir mobiliojo telefono ekranuose, naujausiose Microsoft Edge, Mozilla Firefox, Google Chrome, Apple Safari naršyklėse.
3Informacija VTL IS turi būti koduojama UTF-8 koduote.
4VTL IS naudotojo sąsajos grafinis dizainas turi būti kuriamas pagal gerąsias praktikas.
5Diegėjas turi pateikti ne mažiau kaip 3 skirtingas pagrindinių VTL IS puslapių dizaino kryptis (UI prototipus) derinimui.
6Pagrindinės naudotojui aktualios VTL IS formos turi būti pasiekiamos optimaliai greitai (trijų paspaudimų taisyklė).
7Diegėjas turės atlikti UI/UX tyrimą, apimantį visas ekrano versijas ir Programėlę, su ne mažiau kaip 3 personomis.
8HTML dokumentai turi būti korektiški ir atitikti ne žemesnės kaip HTML5 versijos specifikaciją.
9Privalomi įvedimo laukai turi būti nurodyti ir vienodai pažymėti.
10Visi įvedimo laukai turi būti tikrinami (validation), klaidų pranešimai pateikiami šalia laukų.
11Šalia įvedimo laukų turi būti numatytas užuominų ir paaiškinimų pateikimas.
12Naudotojo sąsajos klaidų, sėkmės, informaciniai pranešimai turi būti aiškūs, nurodant veiksmus, ir išskirti skirtingomis spalvomis/simboliais.
13Duomenų įvedimo formose duomenų laukai turi būti užpildomi automatiškai, pernaudojant saugomus duomenis.
14Ilgai trunkantys procesai turi būti nustatomi ir atvaizduojami progreso indikatoriais (procentiniai indikatoriai, progreso juostos).
15Naudotojui nutraukiant veiksmą, sistema turi pateikti pranešimą ir paprašyti patvirtinti nutraukimą, jei atlikti, bet neišsaugoti pakeitimai.
16VTL IS visos lentelės turi turėti vieningą funkcionalumą (rikiavimas, puslapiavimas, įrašų skaičius, filtrai, greita ir išplėstinė paieška).

Parduotuvės funkcionalumas

1Pagrindiniame Parduotuvės puslapyje turi būti galimybė pasiekti sandorių krepšelį, platinamų ir anksčiau platintų VTL emisijų puslapius, Naujienų ir DUK sritis, bei Kliento paskyrą.
2VTL emisijų puslapyje turi būti galimybė naudotis VTL skaičiuokle, apskaičiuojant gaunamų palūkanų sumą koreguojant investuojamą sumą ir trukmę.
3VTL emisijų puslapyje turi būti numatyta peržiūra dviem būdais (sąrašas (list) arba tinklelis (grid)).
4Išorės naudotojas gali įtraukti sandorį į krepšelį iš skaičiuoklės arba tiesiogiai iš VTL emisijos sąlygų.
5Emisijos peržiūros puslapyje turi būti pateikiama informacija apie VTL (ISIN kodas, pavadinimas, platinimo kaina, galutinio išpirkimo terminas ir kaina).
6Sandorių krepšelio peržiūros puslapyje sandoriai turi būti pateikiami lentelės pavidalu, su informacija apie VTL emisijos ISIN kodą, kiekį, vieneto ir galutinę kainą, bei suminę kainą.
7Sandorių krepšelyje turi būti rodoma aktuali sandorių informacija, o nevalidžius sandorius išorės naudotojas turi pašalinti.
8VTL emisijos su tais pačiais ISIN kodais, kaina ir galutinio išpirkimo terminu krepšelyje turi būti konsoliduojamos.
9Išorės naudotojas gali pašalinti VTL emisijos sandorį iš krepšelio.
10Išorės naudotojas gali koreguoti į krepšelį įtrauktas VTL emisijas: keisti įsigyjamų VTL kiekį.

Avarinis sistemos atstatymas

1Visiško neveikimo atveju VTL IS ar jo dalis komponentų būtų atstatyti per ne ilgesnį nei 2 (dvejų) valandų laikotarpį.
2Diegėjas privalo parengti ir pateikti dokumentuotą sistemos avarinio atstatymo procedūrą (scenarijai, atsarginių kopijų tvarka, konfigūracijų/raktų atkūrimas, diegimo atstatymo scenarijus).
3Avarinio atstatymo pratybos turi būti atliekamos ne rečiau kaip 1 kartą per metus.

Programėlės funkcionalumas

1Programėlė Google Play ir Apple Store parduotuvėse viešinama nemokamai.
2Programėlė turi būti integruota su VTL IS Parduotuvės moduliu ir atvaizduoti VTL IS funkcionalumą.
3Programėlė turi automatiškai informuoti išorės naudotojus apie galimus atnaujinimus.
4Programėlė turi užtikrinti galimybę atnaujinti naršymo lango turinį realiuoju laiku (hot reload ar live update).
5Programėlė turi turėti įdiegtus biometrinės autentifikacijos metodus (veido atpažinimą, pirštų atspaudų nuskaitymą), naudojant įrenginio OS infrastruktūrą (pvz., iOS Face ID / Touch ID, Android BiometricPrompt).
6Biometrinė autentifikacija aktyvuojama tik po sėkmingo pirmo prisijungimo per VIISP, susiejant įrenginį su Kliento paskyra.
7Programėlė turi palaikyti informacinių ir sisteminių pranešimų siuntimą naudotojui.
8Atsiskaitymas programėlėje turi būti realizuotas integruotai (in-app), užtikrinant vientisą naudotojo patirtį, naudojant WebView, App2App arba decoupled SCA metodus.

Diegimas ir aplinkų valdymas

1VTL IS kūrimo, įdiegimo, ištestavimo, išbandymo ir parengimo bei pateikimo darbinei eksploatacijai veiklų atlikimo terminas – 8 mėnesiai nuo sutarties įsigaliojimo dienos.
2Diegėjas turi vadovautis iteraciniu – inkrementiniu (agile) informacinių sistemų kūrimo būdu, darbai planuojami dviejų-trijų savaičių iteracijomis.
3Diegėjas privalo realizuoti audito žurnalų mechanizmą, registruojantį svarbiausius sistemos veiksmus.
4Programavimo (DEV), testavimo (TEST) ir produkcinė (PROD) aplinkos turi būti griežtai atskirtos, negali dalintis tais pačiais duomenimis ar konfigūracijomis.
5Testavimo ir programavimo aplinkose negali būti naudojami realūs produkciniai duomenys; jei būtina, jie turi būti anonimizuoti arba pseudonimizuoti.
6Prieiga prie kiekvienos aplinkos turi būti suteikiama pagal mažiausios privilegijos principą, o kūrėjai neturėtų tiesioginės prieigos prie produkcijos duomenų.
7Kiekviena aplinka turi turėti atskirus API raktus, DB slaptažodžius, sertifikatus ir šifravimo raktus.
8Diegimai į produkcinę aplinką turi būti atliekami tik per autorizuotą CI/CD procesą po sėkmingų testų neprodukcinėse aplinkose.
9Produkcinė aplinka turi būti stebima 24/7.
10Diegėjas turi numatyti ir paruošti automatinio integravimo ir diegimo (CI/CD) įrankius (pvz., Jenkins, Bamboo).
11Prieiga prie CI/CD sistemos turi būti ribojama pagal mažiausios privilegijos principą, visi veiksmai registruojami.
12CI/CD sistemoje negali būti saugomi slaptažodžiai, API raktai nešifruota forma, visi slapti duomenys saugomi saugioje raktų saugykloje.
13CI/CD procese turi būti integruoti automatiniai saugumo testai (SAST, dependency scanning), o kritiniai pažeidžiamumai turi būti blokuojantys diegimą.
14Visi artefaktai turi būti saugomi saugioje, kontroliuojamoje saugykloje, versijuojami ir tikrinami dėl vientisumo.
15CI/CD serveriai turi būti reguliariai atnaujinami ir kietinami, infrastruktūra izoliuota nuo produkcinės aplinkos.
16Diegėjas turi parengti diegimo planą, kuriame nurodomos atsakomybės, veiklų aprašymai, grafikas, schema ir techniniai reikalavimai.
17Diegėjas turi numatyti, kad programinio kodo, aplikacijų, duomenų bazių atnaujinimas būtų atliekamas automatizuotai, be papildomų naudotojo veiksmų (zero touch deployment).
18Diegimo metu Diegėjas turi peržiūrėti ir tinkamai sukonfigūruoti esamus tinklo apsaugos nustatymus.
19Diegėjas turi numatyti VTL IS priežiūrą (pakeitimų, atnaujinimų diegimą) nestabdant sistemos (zero downtime maintenance).

Autentifikavimas ir registracija

1Svečias jungdamasis per Valstybės informacinių išteklių sąveikumo platformą (VIISP) turi turėti galimybę pasirinkti vieną iš šių autentifikacijos būdų: Smart-ID, Mob. parašas, Elektroninė bankininkystė.
2Autentifikacijos funkcionalumas turi užtikrinti duomenų saugumą pagal BDAR reikalavimus, aiškų naudotojo informavimą ir galimybę susieti kelis autentifikavimo būdus su viena paskyra.
3Kliento registracija vyksta tokiu eiliškumu: Autentifikacija; Paskyros duomenų patvirtinimas/įvedimas, sutikimų pateikimas; Registracijos patvirtinimas; Paskyros sukūrimas.
4VIISP perduoti duomenys (vardas, pavardė ir asmens kodas) negali būti keičiami išorės naudotojo ir turi būti tik skaitomi (read-only).
5El. pašto adresas ir telefono numeris gali būti keičiami išorės naudotojo.
6Paskyra turi būti aktyvuojama tik po el. pašto patvirtinimo, o registracijos nuoroda turi galioti ne ilgiau kaip 24 valandas.
7Nepatvirtintos paskyros (pvz., nepatvirtintas el. paštas) turi būti automatiškai ištrinamos po 24 valandų.
8Klientas turi turėti galimybę prisijungti prie savo paskyros jungdamasis per VIISP vienu iš šių būdų: Smart-ID, Mob, parašas, Elektroninė bankininkystė.
9Klientui neatliekant veiksmų ilgiau nei 5 min., jis turi būti automatiškai atjungiamas nuo paskyros, su įspėjimu likus 1 minutei.

Naudotojų administravimas (TVS)

1TVS turi turėti priemones administruoti naudotojų teises ir roles (teisių grupes).
2TVS turi turėti priemones administruoti naudotojus: sukurti, blokuoti, atblokuoti, suteikti ir pašalinti roles.
3IS administratorius gali valdyti tik paskyrų būsenas ir roles, negali keisti naudotojo sandorių ar finansinių duomenų.
4IS administratorius gali eksportuoti naudotojų sąrašą CSV arba XLSX formatu (minimalūs duomenys: vardas, pavardė, el. paštas, tel. nr., paskyros statusas, paskutinio prisijungimo data).
5VTL IS turi būti realizuotas stiprių slaptažodžių sudarymo mechanizmas (ne mažiau 15 simbolių, bent vienas skaičius, specialus simbolis, didžioji ir mažoji raidė).
6TVS modulyje turi būti galimybė keisti slaptažodžių reikalavimus, nurodyti slaptažodžių keitimo periodiškumą ir kontroliuoti paskutinių slaptažodžių pakartotinį naudojimą.
7TVS modulyje turi būti galimybė nurodyti laikino paskyros blokavimo konfigūraciją (nesėkmingų prisijungimų skaičius, blokavimo trukmė).

Klasifikatorių administravimas (TVS)

1TVS turi turėti priemones valdyti klasifikatorius: kurti, redaguoti, šalinti reikšmes, importuoti klasifikatorius.
2Klasifikatorių įrašai turi būti pateikiami lentelės pavidalu, su paieškos ir filtravimo galimybėmis.
3Klasifikatorių pakeitimai turi būti versijuojami.
4Turi būti palaikomi žinučių temos ir emisijų trukmės klasifikatoriai, su galimybe ateityje įvesti naujus.
5Turi būti galimybė konfigūruoti siunčiamų žinučių temas, nurodant žinučių temą ir išorės naudotojo statusą.

Platformos ir programinės įrangos licencijos

1VTL IS autorinės turtinės teisės turi būti perduotos ir priklausyti Perkančiajai organizacijai neribotą laiką.
2Diegėjas privalo užtikrinti VTL IS naudojamų technologijų ir programinės įrangos legalumą (atviro kodo arba įsigytos/prenumeruotos licencijos).
3Visos licencijos ir prenumeratos, reikalingos VTL IS veikti ir vystyti (programavimo, testavimo, produkcinei aplinkai), turi būti perduotos Perkančiajai organizacijai nuo VTL IS paleidimo produkcinėje aplinkoje.
4Jeigu VTL IS kuriamas naudojant mokamus trečiųjų šalių TVS modulius, jų prenumeratos ir palaikymo kaštai turi būti padengiami Diegėjo iki garantinio laikotarpio pabaigos. Jei įmanoma, įsigyjamos neterminuojamos licencijos.
5Turi būti užtikrinamas ilgalaikis technologijos palaikymas (ne trumpesnis kaip 5 metai) ir galimybė perduoti/perimti projektą kitam tiekėjui be esminių technologinių apribojimų.

Turinio valdymo sistemos (TVS) administravimas

1TVS administravimo ir valdymo priemonės turi būti prieinamos per atskirą administravimo naudotojo sąsają.
2TVS turi turėti turinio publikavimo tvirtinimo procesą (workflow).
3VTL IS turinio administracinės paskyros turi būti vardinės.
4TVS valdymas ir konfigūravimas vykdomas interneto naršyklės pagalba.
5Visi vidaus naudotojų atlikti turinio objektų pakeitimai turi būti versijuojami, su registruojama informacija apie pakeitimus.
6Turi būti numatyta automatinio atsarginio kopijavimo galimybė ir priemonės atstatyti ištrintus turinio objektus.
7TVS turi leisti valdyti VTL IS turinį nenaudojant HTML kalbos žinių.
8TVS priemonėmis turi būti numatyta galimybė nurodyti datą, nuo kada įsigalioja informacijos pasikeitimai.
9TVS turi turėti tekstų stiliaus redagavimo, peržiūros priemones.
10Teksto redagavimo aplinka turi būti Microsoft Word ar kitų lygiaverčių programų aplinkai, su maketavimo funkcijomis, paveikslėlių įterpimu, nuorodų kūrimu.
11HTML redagavimo funkcija turi būti apsaugota nuo XSS rizikų, automatiškai filtruojant pavojingus HTML elementus.
12TVS priemonėmis turi būti galima administruoti VTL IS struktūrą, kurti naujus puslapius, keisti informacijos blokų padėtį, įkelti/naikinti blokus.
13Failų įkėlimo funkcija turi tikrinti failų tipą, dydį ir turinį, leidžiant tik saugius plėtinius (PDF, JPG, PNG).
14TVS priemonėmis kuriamų blokų, elementų kiekis neturi būti ribojamas.
15TVS funkcionalumas turi leisti administruoti DUK: tvarkyti klausimų atsakymų tekstus, grupuoti klausimus pagal temas, sudaryti/keisti klausimų hierarchiją.
16DUK įrašai turi būti versijuojami ir palaikyti akordeono stiliaus blokus.
17TVS turi leisti administruoti asmens duomenų saugumo politikos informaciją, su galiojimo trukmės nustatymu.
18TVS turi leisti administruoti VTL IS naudojimosi taisykles.
19TVS funkcionalumas turi leisti administruoti pranešimų skelbimo funkcijas, nurodant pranešimo formą, rodymo datas ir prioritetus.
20TVS turi būti lanksti ir turėti papildomų programavimo galimybių, su dokumentuotu API integracijai su kitomis VTL IS dalimis.

VTL emisijų ir sandorių administravimas (TVS)

1VTL emisijų sąlygos bus importuojamos iš VIKSVA suderintu formatu.
2TVS turi turėti priemones administruoti VTL emisijas (jų katalogus).
3VTL emisijų duomenys (ISIN kodas, pavadinimas, nominali vertė, palūkanų norma, platinimo/išpirkimo datos ir kainos) bus importuojami iš VIKSVA, su galimybe importuoti ir iš failo.
4TVS priemonėmis turi būti galimybė koreguoti emisijos informaciją (pardavimas Parduotuvėje, aprašymas, nuotraukos, savybės).
5Emisijų parametrai, gauti iš VIKSVA, yra tik skaitomi (read-only) VTL IS, išskyrus tuos, kurie nėra tiesiogiai sinchronizuojami.
6TVS turi turėti emisijų pakeitimų tvirtinimo mechanizmą (workflow), su pranešimais autoriui ir audito žurnalais.
7Agreguoti VTL platinimo ir priešlaikinio išpirkimo sandorių duomenys turės būti eksportuojami į VIKSVA suderintu formatu ir dažnumu.

SEO ir pranešimų šablonų administravimas (TVS)

1SEO funkcionalumas turi būti minimalus, skirtas indeksavimui be naudotojų profiliavimo: Meta žymų valdymas, URL struktūra, XML sitemap generavimas, robots.txt valdymas, Schema.org palaikymas, socialinių tinklų metaduomenys, daugiakalbės svetainės palaikymas.
2SEO funkcionalumas negali apdoroti ar perduoti asmens duomenų, indeksuojamas tik viešas turinys.
3TVS turi turėti funkcijas administruoti naujienlaiškius ir el. laiškų šablonus (peržiūra, redagavimas, kūrimas, kopijavimas, galiojimo datos).
4TVS turi turėti funkcijas administruoti žinučių siuntimą išorės naudotojams (kūrimas, siuntimo būdo pasirinkimas, atributų nustatymas, gavėjų sąrašai, tylos laikai).
5TVS turi turėti funkcionalumą, leidžiantį Turinio valdytojui matyti Klientų žinučių sąrašą, rūšiuoti ir atsakyti į jas.

Integracijos su išorinėmis sistemomis (funkciniai)

1VTL IS ir VIKSVA integracija realizuojama REST API pagrindu.
2Mokėjimų žinutėms naudojamas ISO 20022 standartas (PAIN.001 ir patvirtinimo pranešimai).
3Sąskaitos srautams naudojamas CAMT.053 arba VIKSVA palaikomas lygiavertis formatas.
4Atsarginis duomenų mainų kanalas – SFTP.
5Visi API kvietimai tarp VTL IS ir VIKSVA autentifikuojami naudojant OAuth 2.0 (client credentials flow) arba mutual TLS (mTLS).
6Sistema turi užtikrinti apsaugą nuo dvigubo apdorojimo – pakartotinai gautas pranešimas neturi sukelti dvigubo registravimo ar mokėjimo vykdymo.
7VTL IS turi priimti ir saugoti iš VIKSVA gaunamus emisijų parametrus: ISIN kodas, pavadinimas, nominali vertė, valiuta, palūkanų norma, mokėjimo ir platinimo datos, išpirkimo ir priešlaikinio išpirkimo informacija.
8Emisijų parametrai, gauti iš VIKSVA, VTL IS yra tik skaitomi (read-only), išskyrus tuos, kuriuos leidžiama koreguoti administravimo procedūrose.
9Pasikeitus emisijų sąlygoms VIKSVA, VTL IS automatiškai atnaujina rodomus parametrus ir invaliduoja krepšelius, kuriuose pasikeitė kaina.
10Visiems per VTL IS platinamiems VTL naudojamas vienas valstybės iždo IBAN sąskaitos numeris, gaunamas iš VIKSVA.
11VTL IS generuoja unikalų agreguoto sandorio identifikatorių (agr. Id) kiekvienam grupiniam vienetui, apimančiam individualius investuotojų sandorius pagal emisiją ir operacijos tipą.
12Individualaus sandorio požymis (UUID formatu) saugomas VTL IS ir naudojamas PAIN.001 žinutėje endtoendid lauke.
13Rekonsiliacija vyksta agreguoto sandorio lygiu, VTL IS kaupiant individualius SETTLED sandorius ir priskiriant juos agr. Id.
14VTL IS turi teikti VIKSVA struktūrizuotą agreguotų sandorių ir operacijų ataskaitą kiekvienai darbo dienai (Agr. Id, emisija, operacijos tipas, laukiama lėšų gavimo data, bendra suma, sandorių skaičius).
15VTL IS turi gebėti gauti iš VIKSVA dienos sąskaitos srautus ir mokėjimų vykdymo patvirtinimus.
16VTL IS automatiškai grupuoja išeinančius mokėjimus į PAIN.001 žinutes pagal emisiją, operacijos tipą ir mokėjimo datą.
17Kiekvienoje PAIN.001 žinutėje turi būti emisija, operacijos tipas, vykdymo data, bendra kontrolinė suma, mokėjimų sąrašas (gavėjo vardas, pavardė, IBAN, suma, valiuta, individualaus sandorio požymis).
18VTL IS turi palaikyti paketo patvirtinimo seką: generuoja PAIN.001, pateikia VIKSVA patvirtinimui, po patvirtinimo Gateway vykdo mokėjimus.
19VTL IS generuoja tarpines ir galutines suderinimo ataskaitas, lyginant srautus su gautų lėšų duomenimis iš VIKSVA.
20Agr. ID laikomas nesuderintu, jei per nustatytą laikotarpį gautos lėšos nesutampa su laukiama suma, inicijuojant išimčių procedūrą.
21Investuotojo sandoris rodomas kaip 'Apmokėta' nuo MIPT patvirtinimo momento, nepriklausomai nuo faktinio lėšų įskaitymo datos.
22Turi būti galimybė IS administratoriui sukurti naują naudotoją portfelio perkėlimui.
23Turi būti galimybė Veiklos administratoriui inicijuoti perkėlimą, nurodant perdavėją, gavėją, kiekį ir teisinį pagrindą, su IS administratoriaus patvirtinimu (keturių akių principas).
24Mirusio Kliento paskyra užblokuojama naujų sandorių sudarymui, o esami VTL priskiriami laikinai sustabdytai būsenai iki perkėlimo patvirtinimo.

Dokumentai10

2 RK priedas. 4 priedas. Minimalūs reikalavimai tiekejams.docx
3 RK priedas. 7 priedas. ENV metodika_sanaudos.docx
4 RK priedas. 6 priedas. Pasiūlymo forma.VTLP.docx
5 RK priedas. VTL IS TS RK2_EN.docx
7 RK priedas. 10 priedas. SutartiesBendrosios sąlygos.VTLP.docx
Invitation (kvietimas_EN).docx
2862_7978497.pdf
1 RK priedas. VTL IS TS RK2.docx
6 RK priedas. 10 priedas. Sutarties Specialiosios sąlygos.VTLP.docx
Kvietimas.docx

tendis.lt · Sukurta recodin.lt