Soluții · Servicii financiare
O aplicație pentru servicii financiare se judecă după ce se întâmplă la marginile ei: ce se scrie în jurnal, ce se întâmplă când clientul își cere datele înapoi, ce se vede din informarea precontractuală și ce se întâmplă când o sarcină programată nu rulează. Construim mecanica; politica de creditare rămâne a ta.
Construit dejaO platformă de creditare în producție, verificabilă din exterior azi: partea publică e o aplicație compilată static cu 50 de ecrane, între care patru calculatoare — credit, eligibilitate, refinanțare, grafic de plăți — pagini pe tip de credit, informare precontractuală și o rută prin care clientul își cere datele personale; partea de business e un backend modular în TypeScript cu 16 module și 18 tabele în schema de date, între care contract, plată, jurnal de audit, cerere privind datele personale, document încărcat, instantaneu zilnic de indicatori și rulare de sarcină programată. Harta de site de pe producție listează 227 de adrese, iar rutele românești și cele rusești răspund amândouă — verificate de mine pe 06.09.2026. Rezerva pe care o spunem: dovada e din cod și din răspunsurile publice, nu din comportamentul intern al serverului — nu am verificat pe ce versiune rulează producția și nici că toate cele 16 module sunt active pe live.
O companie de creditare nu are nevoie de un site. Are nevoie de un lanț complet: cererea intră online, trece printr-un flux de decizie, produce un contract, generează un grafic de plăți și lasă urmă în audit. Fiecare verigă lipsă din lanț se transformă într-un om care copiază date dintr-un loc în altul, iar în servicii financiare fiecare copiere manuală e și o problemă de conformitate, nu doar de timp.
Structura pe care o construim reflectă asta direct în date. În platforma pe care o cităm, schema are 18 tabele, iar lista lor spune mai mult decât orice descriere de arhitectură: cerere, contract, plată, cod de unică folosință, sesiune, cerere de apel, șablon de notificare, jurnal de notificări, instantaneu zilnic de indicatori, rulare de sarcină programată, articol, redirecționare de adresă, setare de vizibilitate, notă internă, jurnal de audit, document încărcat, cerere privind datele personale. Backendul e împărțit în 16 module, între care unul dedicat exclusiv drepturilor persoanei vizate.
Partea publică nu e decor: patru calculatoare — credit, eligibilitate, refinanțare și grafic de plăți — plus pagini separate pe tip de credit și informarea precontractuală. În creditarea de consum, informarea precontractuală nu e o pagină de imagine: e obligația de a arăta condițiile înainte ca omul să se angajeze. O tratăm ca pe o cerință a produsului, nu ca pe un text juridic lipit la sfârșit. Rutele românești rămân fără prefix, iar cele rusești merg pe un segment propriu, cu etichete canonice și alternative generate din limba rutei active.
Iar limita care trebuie spusă înainte de contract: fluxul de decizie asupra cererilor — regulile, pragurile, aprobarea — e al tău. Noi construim mecanica prin care cererea circulă, se documentează și devine contract. Nu scriem politica de creditare și nu ne asumăm evaluarea unui solicitant; sunt decizii cu consecințe juridice care aparțin instituției autorizate.
Ce cuprinde
Cererea intră online și trăiește ca entitate proprie, cu stare vizibilă și cu ecran de urmărire pentru client. Documentele încărcate au tabela lor, contractul are tabela lui, plata pe a ei. Diferența față de un formular care trimite un e-mail e că, peste trei luni, se poate răspunde din date la întrebarea „ce s-a întâmplat cu cererea din 12 martie”.
Contractul și graficul nu se compun manual într-un document separat: ies din datele cererii aprobate. E singura variantă în care cifra din contract și cifra din grafic nu pot să difere, iar clientul care sună cu documentul în mână vorbește despre același lucru ca operatorul care se uită în sistem.
Credit, eligibilitate, refinanțare și grafic de plăți — ecrane separate, publice, fără autentificare. În creditarea de consum, calculatorul e prima interacțiune reală: omul vrea să vadă rata înainte să vorbească cu cineva. Iar refinanțarea e un calculator diferit de cel de credit, nu același cu alte etichete.
Pagină proprie, nu un paragraf în subsol. Motivul e practic: dacă informarea nu e pe traseul pe care merge omul înainte de a semna, nu își face treaba nici pentru el, nici pentru instituție. Textul e al tău și al juriștilor tăi; noi construim locul, momentul și trasabilitatea.
Există o pagină publică prin care clientul își cere datele personale, un modul de backend dedicat și un ecran de administrare pentru cererile primite, plus o tabelă în care ele trăiesc. Consecința practică: termenul legal de răspuns poate fi respectat fără ca cineva să deschidă baza de date manual — și se poate demonstra, peste un an, că a fost respectat.
Jurnalul de audit e o tabelă proprie, distinctă de notele interne ale operatorilor. Separarea contează la o verificare: una e evidența tehnică a ce s-a întâmplat, alta e ce a scris un coleg despre un dosar. Amestecate, prima devine necitibilă și a doua devine document.
Există o tabelă pentru rulările sarcinilor programate și una pentru instantaneele zilnice de indicatori. Într-o platformă financiară, o sarcină care nu a rulat trei nopți la rând e o problemă mai gravă decât o pagină căzută: nu se vede din exterior, dar mută cifrele. De aceea rularea se scrie, nu se presupune.
Rutele românești rămân fără prefix, cele rusești merg pe un segment propriu, cu etichete canonice și alternative generate din limba rutei active. În harta de site de pe producție sunt 227 de adrese. Pentru o companie de creditare din Republica Moldova, partea rusă nu e o traducere de curtoazie — e jumătate din solicitanți.
Verificări dinainte de publicare, migrări de bază de date rulate cu comandă separată în producție, generare de secrete, copie de siguranță și restaurare a bazei — toate ca scripturi în depozit, nu ca pași dintr-un document. Într-un sistem care ține contracte și plăți, „restaurare” trebuie să fie o comandă pe care ai încercat-o, nu o intenție.
Traseul
Ce înseamnă o cerere depusă, o cerere aprobată, o plată încasată; ce se întâmplă cu o cerere la care nu s-a răspuns; ce cade închis când un serviciu extern nu răspunde. Livrăm documentul de vocabular și invariante, pentru că într-o platformă financiară un termen folosit în două sensuri devine, mai târziu, două cifre diferite în două rapoarte.
Jurnalul de audit și evidența documentelor nu se adaugă la final; sunt parte din prima versiune care funcționează. Livrăm fluxul complet de la cerere la contract, cu urma lui, pe date de test — nu ecrane care arată bine peste o bază goală.
Ecranele publice, calculatoarele, paginile pe tip de credit și informarea precontractuală, cu adresele românești fără prefix și cele rusești pe segment propriu, cu etichete canonice corecte. Livrăm harta de site generată din date și verificarea că ambele versiuni răspund.
Verificare dinainte de publicare, migrări în producție cu comandă separată, generare de secrete, copie de siguranță și restaurare — probate, nu doar scrise. Predăm depozitul, documentul de punere în funcțiune și accesele. Restaurarea bazei se demonstrează la predare, o dată, în fața voastră.
Datele
Regulile diferă de la o industrie la alta. Acestea sunt cele care se aplică în servicii financiare.
Un caz
Situația
Cerința inițială într-un proiect de creditare sună aproape întotdeauna la fel: „un site cu formular de cerere”. Problema apare la a doua lună, când cineva întreabă unde e contractul, cine a modificat dosarul și cum răspundem unei cereri de acces la date personale în termenul legal.
Ce am construit
Am construit platforma în două jumătăți, în același depozit. Partea publică e o aplicație compilată static, cu 50 de ecrane: patru calculatoare — credit, eligibilitate, refinanțare, grafic de plăți — pagini pe tip de credit, informare precontractuală, urmărirea stării cererii și o pagină prin care clientul își cere datele personale. Partea de business e un backend modular în TypeScript, cu 16 module — între care autentificare, drepturi pe rol, fluxul cererilor, documente, plăți, notificări, sarcini programate și unul dedicat drepturilor persoanei vizate — peste o schemă cu 18 tabele: cerere, contract, plată, cod de unică folosință, sesiune, document încărcat, jurnal de audit, cerere privind datele personale, rulare de sarcină programată, instantaneu zilnic de indicatori și restul.
Ce a ieșit
Lanțul e complet: cererea intră, circulă, produce contract și grafic, iar fiecare pas lasă urmă. Cererile privind datele personale au traseu propriu, cu ecran de administrare, deci termenul legal se poate respecta și demonstra. Partea publică e verificabilă din exterior: 227 de adrese în harta de site, cu ambele versiuni de limbă vii.
Ce nu spune cazul
Dovada e din cod și din răspunsurile publice, nu din comportamentul intern al serverului: nu am verificat pe ce versiune rulează producția și nici că toate cele 16 module sunt active pe live. Fluxul de decizie asupra cererilor — reguli, praguri, aprobare — aparține clientului; noi am construit mecanica, nu politica de creditare.
Întrebări
Voi. Regulile, pragurile și aprobarea sunt politica instituției autorizate, nu a furnizorului de software. Noi construim mecanica prin care cererea circulă, se documentează, devine contract și grafic de plăți, și lasă urmă. Un furnizor care își asumă decizia de creditare vinde ceva ce nu are dreptul să vândă.
Există o pagină publică prin care o cere, un modul de backend dedicat, un ecran de administrare și o tabelă în care cererea trăiește. Deci se poate răspunde în termen și se poate demonstra ulterior. Ce nu e o decizie tehnică: ce se poate șterge și ce trebuie păstrat conform legislației financiare — asta se stabilește cu juriștii voștri, înainte de implementare.
Din datele cererii aprobate, împreună cu graficul de plăți — ambele din aceeași sursă, ca să nu poată diferi. Ce rămâne al vostru e conținutul contractului și condițiile lui. Un contract compus manual într-un document separat e locul clasic în care apar două cifre diferite pentru același împrumut.
Pentru că în creditarea de consum informarea trebuie să fie pe traseul pe care merge omul înainte de a se angaja, nu într-un subsol. O tratăm ca parte a produsului: locul, momentul și trasabilitatea sunt ale noastre, textul e al juriștilor voștri.
Cel puțin cele care corespund unor decizii diferite. În platforma pe care o cităm sunt patru — credit, eligibilitate, refinanțare, grafic de plăți — pentru că refinanțarea nu e același calcul cu creditul nou, iar graficul răspunde la altă întrebare decât rata. Un singur calculator cu multe câmpuri e mai greu de folosit decât patru simple.
Nu, și e o regulă, nu o preferință: construim și testăm pe date de test. Accesul la date reale, când e necesar, se face cu persoane numite, pe o perioadă stabilită și cu urmă în jurnal. Într-un sistem financiar, „am avut nevoie să mă uit în producție” e o propoziție care trebuie să apară într-un jurnal, nu într-o discuție.
Se vede, pentru că rulările se scriu într-o tabelă proprie, alături de instantaneele zilnice de indicatori. E important tocmai pentru că o sarcină care nu a rulat nu produce niciun simptom vizibil din exterior — site-ul răspunde, ecranele arată bine, dar cifrele nu se mai mișcă.
Nicio cifră de volum, de dobândă, de număr de cereri sau de clienți, chiar dacă e afișată public pe site-ul lui — pentru că e afirmația lui, nu măsurătoarea noastră. Ce putem arăta e structura: câte module, ce tabele, ce ecrane publice, ce se verifică la publicare. Aceeași regulă se va aplica și lucrării voastre.
Partea publică se poate verifica acum: harta de site are 227 de adrese, iar versiunile română și rusă ale unui calculator răspund amândouă. Partea de backend e citită din cod — module și schema de date — nu din comportamentul serverului: nu am verificat pe ce versiune rulează producția și nici că toate modulele sunt active pe live, și preferăm să scriem asta decât să lăsăm impresia contrară.
Povestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.