Aplicatie Informatica Privind Realizarea Unui Ghiseu Bancar Virtual
Introducere:
Reformele economice și necesitatea crescândă a economiei naționale în resurse financiare au devenit unii din principalii factori pentru diversificarea spectrului serviciilor bancare și a metodelor de satisfacere a necesităților agenților economici.
Această lucrare își propune realizarea unui ghișeu bancar virtual. Pentru început vom prezenta conceptul de ghișeu virtual. El este de cele mai multe ori asociat cu mai bine cunoscutul concept de home banking sau banca la domiciliu.
Această sintagmă este un termen nou, utilizat în practica bancară contemporană si se referă la posibilitatea băncilor de a oferi clienților serviciul bancar la domiciliu. Folsind metode electronice, clienții au acces la conturile lor fără să-și părăsească domiciliul.
Aceasta presupune de cele mai multe ori faptul că un client al băncii să poată realiza anumite operații cu conturile sale fără a mai fi necesar să se prezinte la ghișeul băncii. Acest lucru are mai multe implicații în general pozitive, dar trebuie să ținem cont și de anumite riscuri ce implică securitatea acestor servicii și confidențialitatea operațiilor și a datelor personale ale clienților.
Avantajele unui astfel de sistem sunt numeroase, printre cele mai importante amintim :
rapiditatea desfășurării tranzacțiilor clientul băncii putând desfășura astfel un număr mai mare de tranzacții într-un mod elegant și comod fără a mai cheltui timp și bani cu prezentarea la ghișeele băncii;
evitarea aglomerației la ghișeele băncii ;
mobilitatea clientului, acesta putând folosi acest serviciu din orice oraș.
Acces la serviciile băncii 24 de ore din 24, 7 zile din 7;
Evidența zilnică a operațiunilor efectuate în cont;
Simplificarea procedurilor legate de efectuarea plăților în lei și valută, precum și a celor legate de obținerea extrasului de cont;
Accelerarea schimbului de informații între client și banca;
Reducerea costurilor legate de comisioane;
Dezavantajele unui astfel de sistem țin în principal de securitatea sa, de prevenirea accesului neautorizat la informațiile confidențiale ale clienților băncii sau de realizarea unor anumite operațiuni bancare în numele acestora de către persoane răuvoitoare.
Caracteristica principală a unui sistem informatic bancar modern este nivelul de conectivitate asigurat între factorii implicați in activitatea bancară.
Din acest punct de vedere evoluția sistemelor informatice bancare presupune implementarea succesivă sau directă a următoarelor tipuri de sisteme informatice:
– sisteme informatice bancare fără conectivitate: sunt caracterizate prin existența unor PC-uri independente pe care rulează aplicații specifice anumitor compartimente: contabilitate, creditare etc. Transferul de date intre calculatoare este asigurat de regula prin intermediul suporților externi (dischete). Acest tip de sisteme informatice este întâlnit îndeosebi in unitățile bancare de dimensiuni mai mici (agenții, filiale);
– sisteme informatice bancare cu conectivitate locala: sunt sisteme informatice bazate pe rețele locale de calculatoare;
– sisteme informatice bancare cu conectivitate globală: sunt sisteme informatice bazate pe rețele de arie întinsă (WAN) care conectează rețelele locale (LAN) ale unităților bancare.
Construirea unui sistem informatic pleacă de la întrebarea: ce activități informatizam? și continuă cu răspunsul la întrebarea: cum?
În mod generic, un produs informatic de tip banca la domiciliu sau home banking bazat pe conectivitate globală ar putea fi de forma unei aplicații client server. Astfel clientul băncii se conectează folosind propriul computer dotat cu un modem la computerul băncii, acesta fiind pe post de server.
Desigur acest lucru implică și o dotare minimală a clientului cu un computer personal de tip compatibil IBM și un modem și evident o linie telefonică sau un telefon mobil pentru a putea fi realizată o conexiune cu computerul băncii.
Home banking definește accesul la serviciile bancare din exteriorul sediului unității bancare. Acest acces se poate realiza prin intermediul unui simplu telefon conectat la o centrală telefonică și prin intermediul unui calculator personal.
O alternativă la home banking este reprezentată de accesul la servicii bancare prin telefon (telephone banking) care se realizează astfel: de la un telefon cu tastatura se formează numărul serviciului bancar telefonic, după terminarea mesajelor emise de robotul telefonic (placa voice-teller plus software-ul aferent) se tastează codul numeric personal (PIN), apoi se tastează codul operației ce se dorește a se efectua asupra contului curent.
În prezent, acest tip de serviciu este întâlnit la unele bănci din țară, dar este orientat în principal spre informarea clientului privind starea conturilor sale.
Clientul poate obține informațiile sub forma de voce sau fax.
Accesul la servicii bancare prin intermediul unui calculator personal presupune conectarea calculatorului personal al clientului băncii prin intermediul unei linii telefonice si a unui modem la calculatorul băncii. Comunicația si accesul la serviciile bancare sunt controlate de un program specializat furnizat de banca instalat pe calculatorul clientului. De fapt, calculatorul clientului devine un ATM virtual. Se pot ordona plăți, se pot obține informații privind starea contului etc.
În general o astfel de aplicație permite clienților băncii să afle în timp real detalii despre situația curenta a conturilor / depozitelor / creditelor , istoricul operațiunilor și să efectueze operațiuni fără a se deplasa la sediul băncii.
În băncile românești există o mare varietate de sisteme informatice, utilizarea serviciilor bancare bazate pe tehnici moderne fiind încă intr-un stadiu incipient. Acest lucru poate constitui un avantaj deoarece se pot alege de la bun început soluțiile optime verificate de practica bancara internațională.
Implementarea metodelor moderne în activitatea bancară românească necesită nu doar eforturi financiare deosebite. Trebuie depășite mentalități care încă mai persistă atât la nivelul factorilor decizionali, cât și la nivelul consumatorului de servicii bancare. Introducerea metodelor moderne in sistemul bancar trebuie să fie rezultanta a doua tendințe convergente. Pe de o parte, societățile bancare urmăresc creșterea operativității prin introducerea tehnicii de calcul și a metodelor moderne.
CAPITOLUL I
1.1.Prezentarea Băncii Române pentru Dezvoltare – S.A.
Denumirea, sediul, durata și obiectivul de activitate
BANCA ROMÂNĂ PENTRU DEZVOLTARE se constituie ca societate pe acțiuni, organizată în conformitate cu legile în vigoare în România și funcționează ca persoană juridică română, potrivit prevederilor Legii privind activitatea bancară si prezentului Statut.
În acest Statut JBANCA ROMÂNĂ PENTRU DEZVOLTARE – SA" este denumită BANCA.
BANCA are sediul central în municipiul București si își desfășoară activitatea prin sucursale, filiale, agenții și reprezentanțe în țară și străinătate.
înființarea de noi sucursale, filiale, agenții, reprezentanțe și alte unități se face cu aprobarea Adunării Generale a Acționarilor, în condițiile prevăzute de lege.
Durata de activitate a BĂNCII va fi de 99 de ani, începând cu data publicării în Monitorul Oficial al României a documentelor de înființare.
Obiectul de activitate al BĂNCII îl constituie:
Atragerea de fonduri bănești în lei și în valută de la persoane juridice și fizice, din țară și străinătate, sub formă de depozite sau instrumente nenegociabile, plătibile la vedere sau la termen, acordarea de credite pe termen scurt, mediu și lung, precum și efectuarea altor operațiuni si servicii bancare.
4.2. Efectuarea de operațiuni și servicii bancare pentru proiectele de investiții economice și financiare ce se realizează, integral sau parțial, din fonduri de la buget și din împrumuturi în valută de la băncile de dezvoltare internaționale, instituții financiare și de la alte bănci.
Capital, fonduri și alte resurse financiare
Capitalul social subscris al BĂNCII este de 7.000.000.000 lei, împărțit în 700.000 acțiuni nominative în valoare nominală de 10.000 lei fiecare, putându-se emite și titluri cumulative de 5, 10, 30, 50, 100 și 1000 acțiuni.
Capitalul social este subscris și vărsat integral și va putea fi majorat în condițiile legii și ale prevederilor prezentului Statut.
Acțiunile conferă deținătorilor drepturi și obligații egale. Banca recunoaște un singur proprietar pentru fiecare acțiune. Acționarii răspund numai în limita valorii nominale a fiecărei acțiuni.
Dreptul de proprietate asupra acțiunilor se transmite prin declarația făcută în registrul acțiunilor BĂNCII, subscrisă de cedent și de cesionar sau de mandatarii lor și prin mențiunea făcută pe acțiune.
Subscriitorii și cesionarii ulteriori sunt răspunzători solidar de plata integrală a acțiunilor, timp de 3 ani, socotiți de la data când s-a făcut mențiunea de transmitere în registrul acționarilor.
Când acționarii nu au efectuat plata vărsămintelor ce datorează, Consiliul de Administrație al BĂNCII va decide asupra modalității de rezolvare, potrivit prevederilor legale.
Orice acțiune dă dreptul la un vot în Adunarea Generală a Acționarilor. Exercițiul dreptului de vot este suspendat pentru acționarii care nu sunt la curent cu vărsămintele ajunse la scadență.
Acțiunile sunt indivizibile.
Când o acțiune nominativă devine proprietatea mai multor persoane, BANCA nu este obligată să înscrie transmiterea atâta timp cât acele persoane nu vor desemna un reprezentant unic pentru exercitarea drepturilor rezultând din acțiune.
Atâta timp cât o acțiune este proprietatea indiviză a mai multor persoane, acestea sunt răspunzătoare în mod solidar pentru efectuarea vărsămintelor datorate.
BANCA nu va putea dobândi propriile sale acțiuni, nici acorda împrumuturi sau avansuri asupra lor, în afară de cazul în care Adunarea Generală a Acționarilor hotărăște astfel, cu votul acționarilor care reprezintă două treimi din capitalul social.
Situația acțiunilor trebuie să fie publicată odată cu bilanțul anual și, în mod deosebit, să arate dacă acțiunile au fost integral plătite și numărul acțiunilor pentru care s-a cerut, fără rezultat, efectuarea vărsămintelor.
Majorarea capitalului social se poate face prin emiterea de noi acțiuni în condițiile legii, la perioade și în cuantumul stabilit de Adunarea Generală extraordinară a Acționarilor la propunerea Consiliului de Administrație. Nu se pot emite acțiuni noi de o valoare mai mică decât valoarea nominală inițială.
Persoanele fizice sau juridice din țară pot cumpăra acțiuni în lei și/sau valută. Persoanele fizice sau juridice din străinătate pot cumpăra acțiuni numai în valutele agreate de BANCA la cursul de la data efectuării operațiunii.
Hotărârea adunării pentru mărirea capitalului se va publica în Monitorul Oficial, acordându-se pentru exercițiul dreptului de preferință un termen de cel puțin o lună, cu începere din ziua publicării.
Hotărârea adunării privind mărirea capitalului are efect numai în măsura în care a fost adusă la îndeplinire în termen de un an de la data sa.
Reducerea capitalului social va putea fi făcută numai după trecerea a două luni din ziua în care hotărârea a fost publicată în Monitorul Oficial.
Orice creditor al Băncii, anterior hotărârii va putea face opoziție la instanță, în termenul arătat la aliniatul 1.
Opoziția suspendă executarea hotărârii, până la retragerea sau respingerea ei, printr-o sentință definitivă a instanței.
Când BANCA a emis obligațiuni, nu se va putea proceda la reducerea capitalului prin restituiri făcute acționarilor din sumele rambursate în contul acțiunilor, decât în proporție egală cu valoarea operațiunilor rambursate.
Pentru desfășurarea activității sale, BANCA constituie fondul de rezervă, fondul de risc, fondul de dezvoltare, precum si alte fonduri.
Fondurile BĂNCII se constituie, potrivit reglementărilor legale, din profitul anual și pot fi utilizate pentru finanțarea unor acțiuni economice, financiare, valutare la data sa.
Reducerea capitalului social va putea fi făcută numai după trecerea a două luni din ziua în care hotărârea a fost publicată în Monitorul Oficial.
Orice creditor al Băncii, anterior hotărârii va putea face opoziție la instanță, în termenul arătat la aliniatul 1.
Opoziția suspendă executarea hotărârii, până la retragerea sau respingerea ei, printr-o sentință definitivă a instanței.
Când BANCA a emis obligațiuni, nu se va putea proceda la reducerea capitalului prin restituiri făcute acționarilor din sumele rambursate în contul acțiunilor, decât în proporție egală cu valoarea operațiunilor rambursate.
Pentru desfășurarea activității sale, BANCA constituie fondul de rezervă, fondul de risc, fondul de dezvoltare, precum si alte fonduri.
Fondurile BĂNCII se constituie, potrivit reglementărilor legale, din profitul anual și pot fi utilizate pentru finanțarea unor acțiuni economice, financiare, valutare și de altă natură, în care BANCA este interesată, precum si pentru acoperirea eventualelor pierderi.
Banca utilizează pe lângă capitalul social și fondurile proprii constituite și alte resurse financiare în lei și în valută și anume: disponibilitățile existente în conturile clienților; depozitele din țară și străinătate; obligațiunile și alte titluri de credit emise de BANCA în condițiile legii, precum și alte resurse financiare atrase.
Operațiunile BĂNCII
BANCA efectuează operațiuni bancare și financiare în țară si străinătate, în lei și în valută, pentru contul său propriu, al clienților BĂNCII – persoane juridice sau fizice – în numele unor instituții sau în colaborare cu acestea, astfel:
a) efectuează operațiuni de depozite la vedere și la termen, în cont, cu numerar și cu titluri, constând în atragerea resurselor bănești de la persoane juridice și fizice, în vederea păstrării și fructificării lor. Depozitele pot fi purtătoare de dobândă;
b) păstrează disponibilitățile bănești ale clienților și efectuează operațiuni de încasări și plăți în numerar sau fără numerar, prin conturile deschise clienților la această BANCĂ;
c) contractează împrumuturi de la bănci și alte organisme financiare din țară și străinătate;
d) acordă agenților economici și persoanelor fizice credite pe termen scurt pe durate ce nu depășesc 12 luni; credite pe termen mediu cu rambursare până la 5 ani și credite pe termen lung, cu rambursare de peste 5 ani.
La acordarea creditelor BANCA urmărește ca solicitantul să prezinte credibilitate pentru rambursarea lor la scadență, în acest scop, BANCA poate cere solicitanților garantarea creditului cu bunuri mobile sau imobile;
e) prestează servicii privind expertizarea tehnică, economică și financiară a proiectelor, urmărirea utilizării fondurilor potrivit destinației aprobate și a prevederilor din documentații, analiza efectelor depuse de executanți, precum și alte servicii pentru investițiile statului care se realizează din fonduri de la buget în baza mandatului primit;
f) elaborează și expertizează studii de fezabilitate, acordă consultații și asistență privind gestiunile financiare și efectuează evaluarea patrimoniului pentru clienții băncii și pentru orice alți solicitanți, pe bază de convenții încheiate cu aceștia;
g) se execută transferuri, operațiuni de clearing și alte operațiuni de virament, pe cont propriu sau în contul terților;
h) primește titluri în gaj sau în păstrare;
i) efectuează, potrivit legii și în limita mijloacelor de care dispune, operațiuni valutare; operațiuni cu metale prețioase, cu obiecte confecționate din acestea și cu alte valori cu grad mare de lichiditate; operațiuni de plasament, subscriere, gestionare, păstrare și comerț cu titluri; garanții, mandatari, precum și alte activități legale care pot fi asumate pe cont propriu sau în contul clienților;
j) efectuează operații de arbitrajare pe piețele valutare; BANCA poate compensa din beneficiile realizate din aceste operațiuni eventualele influențe nefavorabile;
k) participă la consorții de garanții și la credite consorțiale interne și internaționale;
l) efectuează servicii de depozitare pentru obiecte de valoare, proprietatea unor persoane juridice sau fizice;
m)efectuează operațiuni privind executarea de casă a bugetului, în limita mandatului primit;
n) încheie aranjamente de corespondent cu bănci si instituții financiare străine și convenții privind activități financiar-bancare și efectuează alte operațiuni legate de afacerile bancare și financiare, în țară și străinătate;
o) participă cu capital la instituții financiare si bancare, și la alți agenți economici, din țară și străinătate, în condițiile prevăzute de lege;
p) participă, ca membru, în organisme financiar-bancare internaționale sau regionale, la operațiuni economice financiare și bancare în cadrul unor acorduri, convenții și înțelegeri încheiate de autoritățile române pe plan internațional;
r) efectuează tranzacții și imobile necesare desfășurării activității BĂNCII și pentru personalul propriu, precum și tranzacții cu imobile și alte bunuri imobiliare în executarea creanțelor BĂNCII;
s) efectuează orice alte activități bancare și financiare permise de reglementările legale în vigoare.
Creditele se acordă de BANCA pe baza contractului de împrumut care are valoare de înscris autentic și constituie titlu executoriu.
În exercitarea atribuțiilor sale, BANCA elaborează norme și instrucțiuni privind creditarea, garanțiile asigurătorii și recuperarea creanțelor BĂNCII, încasările și plățile, operațiunile valutare, celelalte servicii bancare și drepturile de control.
BANCA primește de la clienții săi bilanțurile contabile și contul de profit și pierderi, situația angajamentelor de plată și orice alte informații și date referitoare la lichiditatea, solvabilitatea si rentabilitatea acestora. De asemenea, BANCA are dreptul să verifice situația economică și financiară a clientului, de la acordarea creditului și până la rambursarea integrală a acestuia.
Adunarea Generală a Acționarilor
Adunarea Generală reprezintă totalitatea acționarilor BĂNCII.
Fiecare acționar are dreptul să participe la Adunarea generală personal sau prin alți acționari pe bază de procură specială.
Normele de reprezentare a acționarilor în Adunarea Generală vor fi stabilite de Consiliul de Administrație si aprobate de Adunarea Generală.
Adunările generale sunt ordinare si extraordinare. Ele se vor ține la sediul BĂNCII și în localul ce se va indica în convocare.
Adunarea Generală ordinară se întrunește cel puțin odată pe an, în cel mult trei luni de la încheierea exercițiului financiar.
În afară de dezbaterea altor probleme înscrise la ordinea de zi, Adunarea Generală este obligată:
a) să analizeze și să aprobe bilanțul, contul de profit și pierderi, destinația și repartizarea profitului, dividendele ce se distribuie acționarilor, tantiemele pentru administratori și recompensele ce se acordă funcționarilor, precum și descărcarea din gestiune, pe baza raportului Consiliului de Administrație asupra activității BĂNCII si a raportului comisiei de cenzori;
b) să aprobe bugetul de venituri și cheltuieli și programul de activitate pentru anul financiar următor;
c) să aleagă Consiliul de Administrație, cenzorii și să numească, în condițiile legii, președintele, vicepreședinții și președintele comisiei de cenzori;
d) să aprobe remunerarea președintelui, vicepreședinților și cenzorilor și să fixeze indemnizația membrilor Consiliului de Administrație;
e) să aprobe plasarea unor părți ale fondului de rezervă și ale fondatorilor cu destinație specială în titluri ale statului și în alte valori;
f) să aprobe, la propunerea Consiliului de Administrație, acoperirea creditelor care nu mai pot fi recuperate de la debitori;
g) să aprobe înființarea sau desființarea de sucursale, filiale, agenții sau reprezentanțe ale BĂNCII.
Pentru validitatea deliberărilor Adunării Generale ordinare este necesară prezența acționarilor care să reprezinte cel puțin jumătate din capitalul social, iar hotărârile să fie luate de acționarii ce dețin majoritatea absolută din capitalul social reprezentat în adunare.
Dacă adunarea nu poate lucra din cauza neîndeplinirii condițiilor de la alin. 1, adunarea ce se va întruni, după o a doua convocare, poate să delibereze asupra problemelor puse la ordinea de zi a celei dinții adunări, oricare ar fi partea de capital reprezentată de asociații prezenți, cu majoritate.
Adunarea extraordinară se întrunește ori de câte ori este nevoie de a se lua o hotărâre pentru:
a) prelungirea duratei de funcționare a BĂNCII;
b) mărirea capitalului;
c) mutarea sediului;
d) fuzionarea sau afilierea la alte organisme bancare;
e) refacerea capitalului social sau reîntregirea sa, prin emisiune de noi acțiuni;
f) dizolvarea anticipată a BĂNCII;
g) emisiunea de obligațiuni;
h) oricare altă modificare a Statutului sau oricare altă hotărâre pentru care este cerută aprobarea Adunării extraordinare.
Pentru validitatea deliberărilor Adunării Generale extraordinare sunt necesare:
– la prima convocare prezența acționarilor reprezentând trei pătrimi din capitalul social, iar hotărârile să fie luate cu votul unui număr de acționari care să reprezinte cel puțin jumătate din capitalul social;
– la convocările următoare, prezența acționarilor reprezentând jumătate din capitalul social, iar hotărârile să fie luate cu votul unui număr de acționari care să reprezinte cel puțin o treime din capitalul social.
Adunările generale vor fi convocate de Consiliul de Administrație ori de câte ori va fi nevoie.
Termenul de întrunire în nici un caz nu poate fi mai mic de 15 zile de la publicarea convocării.
Convocarea va fi publicată în Monitorul Oficial și într-unul dintre ziarele răspândite în localitatea în care se află sediul BĂNCII.
Convocarea va cuprinde locul și data ținerii adunării, precum și ordinea de zi, cu arătarea explicită a tuturor problemelor care vor face obiectul dezbaterilor adunării.
Când în ordinea de zi, figurează propuneri pentru modificarea Statutului, convocarea va trebui să cuprindă textul integral al propunerilor.
Consiliul de Administrație este obligat să convoace de îndată Adunarea Generală, la cererea acționarilor reprezentând a zecea parte din capitalul social și dacă cererea cuprinde probleme ce intră în competența adunării.
Adunarea va avea loc în termen de o lună de la cerere.
Dacă Consiliul de Administrație nu convoacă adunarea, instanța judecătorească din raza teritorială unde își are sediul BANCA, cu audierea părților, va putea ordona convocarea, desemnând dintre acționari persoana care o va prezida.
Acționarii exercită dreptul lor de vot în Adunarea Generală, proporțional cu numărul acțiunilor ce posedă, cu excepția prevăzută în art. 8.
Acționarii, reprezentând întreg capitalul social vor putea, dacă niciunul dintre ei nu se opune, să ia orice hotărâre de competența adunării fără respectarea formalităților cerute pentru convocarea ei.
Acționarii nu vor putea fi reprezentați în Adunările Generale decît prin alți acționari, în baza unei procuri speciale.
Membrii Consiliului de Administrație și funcționarii BĂNCII nu pot reprezenta pe acționari, sub sancțiunea nulității hotărârii dacă, fără votul acestora, nu s-ar fi obținut majoritatea cerută.
Membrii Consiliului de Administrație nu pot vota în baza acțiunilor ce posedă nici personal, nici prin mandatar, descărcarea gestiunii lor sau o problemă în care persoana sau atribuțiile lor ar fi în discuție.
Ei pot vota însă bilanțul și contul de profit și pierderi dacă, fiind posesori a cel puțin jumătate din capitalul social, nu se poate forma majoritatea legală fără votul lor.
Acționarul care, într-o anumită operație are, fie personal fie ca mandatar al unei alte persoane, un interes contrar aceluia al BĂNCII, va trebui să se abțină de la deliberările privind acea operație.
Acționarul care contravine acestei dispozițiuni este răspunzător de daunele produse BĂNCII, dacă, fără votul său, nu s-ar fi obținut majoritatea cerută.
Dreptul de vot nu poate fi cedat. Orice convenție privind exercitarea într-un anumit fel a dreptului de vot este nulă.
În ziua și la ora arătate în convocare, ședința adunării se va deschide de către președintele Consiliului de Administrație sau de către acela care îi ține locul.
Președintele va desemna dintre acționari doi sau mai mulți secretari care vor verifica lista de prezență a acționarilor, arătând capitalul pe care-l prezintă fiecare, procesul-verbal întocmit de cenzori pentru constatarea numărului acțiunilor depuse și îndeplinirea tuturor formalităților cerute de lege și de prezentul Statut pentru ținerea adunării, după care se va trece la ordinea de zi.
Hotărârile adunărilor se iau prin vot deschis. Votul secret este obligatoriu pentru alegerea membrilor Consiliului de Administrație și a cenzorilor, pentru revocarea lor si pentru luarea hotărârilor referitoare la răspunderea membrilor Consiliului de Administrație.
Un proces-verbal semnat de președinte și secretar va constata îndeplinirea formalităților de convocare, data și locul adunării, acționarii prezenți, numărul acționarilor, dezbaterile în rezumat, hotărârile luate, iar la cererea acționarilor, declarațiile făcute de ei în ședință.
La procesul-verbal se vor anexa actele referitoare la convocare precum și listele de prezență a acționarilor.
Procesul-verbal va fi trecut în registrul adunărilor generale.
Pentru a fi opozabile terților, hotărârile adunărilor vor fi depuse în termen de 15 zile la registrul comerțului pentru a fi menționate în extras, în registru și publicate în Monitorul Oficial.
Ele nu vor putea fi executate mai înainte de aducerea la îndeplinire a acestor formalități.
Hotărârile luate de Adunările Generale, în limita legii sau Statutului, sunt obligatorii chiar pentru acționarii care nu au luat parte la adunare sau au votat contra.
Hotărârile Adunării Generale contrare Statutului sau legii pot fi atacate în justiție în termen de 15 zile de la data publicării în Monitorul Oficial de oricare dintre acționarii care nu au luat parte la Adunarea Generală sau au votat contra și au cerut să se însereze aceasta în procesul-verbal al ședinței.
Dacă hotărârea este atacată de toți membrii Consiliului de Administrație, BANCA va fi reprezentată în justiție de persoana desemnată 'de președintele instanței dintre acționarii ei, care va îndeplini mandatul cu care a fost însărcinată, până ce Adunarea Generală, convocată în acest scop va alege altă persoană.
Cererea de anulare a hotărârii Adunării Generale se va introduce la instanța din raza teritorială unde BANCA își are sediul, acționarul fiind obligat să depună la grefă cel puțin o acțiune.
Dacă au fost introduse mai multe acțiuni de anulare, ele pot fi conexate.
Cererea se va judeca în camera de Consiliu.
Hotărârea definitivă de anulare va fi menționată în registrul comerțului și publicată în Monitorul Oficial. De la data publicării ea este opozabilă tuturor acționarilor.
Odată cu intentarea acțiunii în anulare, reclamantul poate cere președintelui instanței suspendarea executării hotărârii atacate.
Administrația BĂNCII
Administrația și conducerea BĂNCII este încredințată Consiliului de Administrație (administratori) compus din cel mult 11 membrii, aleși de către Adunarea Generală. Din Consiliul de Administrație fac parte președintele și vicepreședinții, reprezentanți ai acționarilor, precum și specialiști din aparatul BĂNCII și din alte unități.
Membrii Consiliului de Administrație sunt aleși pentru o perioadă de 4 ani, după care pot fi realeși.
La preluarea funcției, fiecare administrator va trebui să depună o garanție care nu poate fi mai mică decât dublul salariului lunar. Garanția se va depune înainte de începutul activității.
Dacă garanția nu va fi depusă, administratorul este considerat demisionat.
Garanția rămâne în casieria BĂNCII și nu va putea fi restituită administratorului decât după ce Adunarea Generală a aprobat bilanțul ultimului exercițiu în care administratorul a funcționat si i-a dat descărcarea.
Semnăturile administratorilor vor fi depuse în registrul comerțului, odată cu prezentarea certificatului eliberat de cenzori, din care rezultă depunerea garanției.
Pentru valabilitatea deciziilor Consiliului de Administrație este necesară prezența personală a cel puțin jumătate din numărul administratorilor.
Deciziile se iau cu majoritatea absolută a membrilor prezenți.
Consiliul de Administrație are următoarele atribuții:
a) examinează și certifică bilanțul contabil, contul de profit și pierderi și propunerile privind destinația și repartizarea profitului, care se prezintă Adunării Generale;
b) aprobă veniturile și cheltuielile, investițiile proprii, reparațiile capitale și actele de dispoziție cu privire la bunurile și mijloacele BĂNCII;
c) aprobă strategiile BĂNCII cu privire la credite, atragerea de resurse, utilizarea acestora, nivelul dobânzilor, comisioanelor, taxelor, marjelor și altor speze bancare;
d) aprobă facilități de credite clienților și împrumuturi care, cumulat, depășesc pe un singur client peste 10% din valoarea capitalului social vărsat plus rezervele, dar nu mai mult de nivelul autorizat de lege. Consiliul de Administrație poate delega competențe de aprobare unui comitet de credit și risc format din directori executivi și specialiști din cadrul BĂNCII;
e) propune Adunării Generale modificarea Statutului, majorarea sau micșorarea capitalului social și constituirea de rezerve, plasarea unei părți din mijloacele financiare ale fondului de rezervă și ale fondurilor de destinație specială în titluri ale statului și alte valori, precum și măsuri pentru încasarea capitalului social;
f) aprobă, în limitele fondurilor stabilite de Adunarea Generală, participarea BĂNCII cu capital la investiții financiare și bancare și la alți agenți economici din țară și din străinătate;
g) propune Adunării Generale emiterea de acțiuni, obligațiuni și alte titluri de valoare și modul de plasare a acestora;
h) aprobă schema de organizare, regulamentele și normele interne de funcționare, funcțiile, atribuțiile și competențele personalului, nivelul și regimul de salarizare, premiile și alte forme de remunerare a personalului;
j) aprobă normele și instrucțiunile privind operațiunile BĂNCII; k) are orice alte atribuții, cu excepția celor din competența expusă a Adunării Generale.
Administratorii sunt răspunzători de îndeplinirea tuturor obligațiilor ce le revin, potrivit dispozițiilor relative la mandat și de cele prevăzute de lege.
Consiliul de Administrație se întâlnește ori de câte ori este necesar. El trebuie să se întâlnească cel puțin o dată pe lună la sediul BĂNCII.
Convocările pentru întrunirile Consiliului de Administrație vor cuprinde locul unde se va ține ședința și proiectul ordinii de zi, neputându-se lua nici o decizie asupra problemelor neprevăzute, decât în caz de urgență și cu condiția ratificării în ședința următoare de către membrii absenți.
La ședința Consiliului de Administrație vor fi convocați și cenzorii.
În fiecare ședință se va întocmi un proces verbal, care va cuprinde ordinea deliberărilor, deciziilor luate, numărul de voturi întrunite și opiniile separate.
Consiliul de Administrație delegă o parte din atribuțiile sale pentru conducerea operativă a BĂNCII unui Comitet de Direcție compus din cel mult 5 membri din rândurile sale și anume: președintele Consiliului de Administrație, vicepreședinții Consiliului de Administrație și alți membri.
Comitetul de Direcție este condus de președintele Consiliului de Administrație care are și calitatea de director general.
Consiliul de Administrație stabilește cu ocazia numirii Comitetului de Direcție împuternicirile, responsabilitățile și remunerația membrilor acestuia.
Decizia Consiliului de Administrație privind suma necesară remunerării membrilor Comitetului de Direcție va trebui să fie ratificată de Adunarea Generală.
Comitetul de Direcție se întrunește cel puțin o dată pe săptămână.
Deciziile Comitetului de Direcție se iau cu majoritatea absolută de voturi a membrilor săi.
Comitetul de Direcție este obligat să prezinte la fiecare ședință a Consiliului de Administrație registrul său de deliberări.
În Comitetul de Direcție votul nu poate fi dat prin delegație.
Activitatea de conducere curentă a BĂNCII este asigurată de președinte sau de înlocuitorul lui de drept.
Președintele angajează BANCA conform responsabilităților și împuternicirilor stabilite de Consiliul de Administrație.
Atribuțiile și competențele vicepreședinților se stabilesc de Consiliul de Administrație la propunerea președintelui.
Angajarea BĂNCII în legătură cu operațiunile patrimoniale se face cu două semnături potrivit competențelor care se stabilesc de Consiliul de Administrație. Angajarea BĂNCII printr-o singură semnătură este nulă.
Directorii executivi nu vor putea fi membri în Consiliul de Administrație al BĂNCII.
Ei sunt răspunzători față de BANCĂ și de terți, ca și administratorii pentru neîndeplinirea îndatoririlor lor, conform dispozițiilor legii.
Nu vor putea fi administratori, directori sau reprezentanți ai societății, persoanele care, potrivit legii, sunt incapabile sau au fost condamnate pentru gestiune frauduloasă, abuz de încredere, fals, înșelăciune, delapidare, mărturie mincinoasă, dare sau luare de mită, precum și pentru alte infracțiuni pedepsite potrivit legii societăților comerciale, iar dacă au fost alese sunt decăzute din drepturi.
Comisia de cenzori
Adunarea Generală alege o comisie de cenzori formată din 3 cenzori și tot atâția supleanți din care cel puțin unul din aceștia trebuie să fie contabil autorizat în condițiile legii sau expert contabil, recomandat de Ministerul Economiei și Finanțelor.
Alegerea Comisiei de cenzori se face pe o durată de 3 ani după care pot fi realeși. La numirea lor, cenzorii vor depune o garanție, potrivit legii.
Cenzorii trebuie să fie acționari ai BĂNCII cu excepția expertului contabil. Nu pot fi cenzori rudele sau afinii până la al patrulea grad inclusiv sau soții membrilor Consiliului de Administrație, persoanele care primesc sub orice formă, pentru alte funcții decât aceea de cenzor, un salariu sau o remunerare de la administratori sau de la BANCĂ, precum și alte persoane incompatibile cu această funcție, prevăzute de lege.
Comisia de cenzori îndeplinește atribuțiile prevăzute de lege și ia hotărâri cu o majoritate de 2/3 din numărul lor.
Membrii comisiei de cenzori sunt răspunzători de eventualele prejudicii aduse BĂNCII prin activitatea lor.
Cenzorii sunt retribuiți cu o indemnizație fixă stabilită de Adunarea Generală.
Cenzorii sunt obligați să supravegheze gestiunea societății, să verifice dacă bilanțul și contul de profit și pierderi sunt legal întocmite și în concordanță cu registrele, dacă acestea din urmă sunt regulat ținute și dacă evaluarea patrimoniului s-a făcut conform regulilor stabilite pentru întocmirea bilanțului.
Despre toate acestea, precum și asupra propunerilor pe care le vor crede necesare asupra bilanțului și repartiției beneficiarilor, cenzorii vor face Adunării Generale un raport amănunțit.
Adunarea Generală nu va putea aproba bilanțul și contul de profit și pierderi, dacă acestea nu sunt însoțite de raportul cenzorilor.
Cenzorii sunt obligați de asemenea:
a) să facă, în fiecare lună și inopinat, inspecții casei și să verifice existența titlurilor sau valorilor ce sunt proprietatea BĂNCII sau au fost primite în gaj, cauțiune ori depozit;
b) să convoace adunarea ordinară sau extraordinară, când n-au fost convocate de administratori;
c) să ia parte la adunările ordinare si extraordinare, putând face să se insereze în ordinea de zi propunerile pe care le vor crede necesare;
d) să se constate regulata depunere a garanției din partea administratorilor;
e) să vegheze ca dispozițiile legii și ale statului să fie îndeplinite de administratori și de lichidatori.
Cenzorii vor aduce la cunoștința administratorilor neregularitățile în administrație si încălcările dispozițiilor legale si statutare pe care le constată, iar cazurile mai importante le vor aduce la cunoștința Adunării Generale.
Cenzorii au dreptul să obțină în fiecare lună de la administratori o situație despre mersul operațiunilor.
Cenzorii iau parte la adunările administratorilor, fără drept de vot. Este interzis cenzorilor să comunice acționarilor în particular sau persoanelor străine, datele referitoare la operațiile sociale, constatate cu ocazia exercitării mandatului lor.
Pentru îndeplinirea obligației prevăzute în art. 55 lit.d, cenzorii vor delibera împreună; ei însă vor putea da, în caz de neînțelegere, rapoarte separate, care vor trebui să fie prezentate Adunării Generale.
Pentru celelalte obligații impuse de lege, cenzorii vor putea lucra separat.
Cenzorii vor trece într-un registru special deliberările lor, precum și constatările făcute în exercițiul mandatului lor.
întinderea și efectele răspunderii cenzorilor sunt determinate de regulile mandatului.
Bilanțul și contul de profit si pierderi
Anul financiar al BĂNCII începe la l ianuarie și se încheie la 31 decembrie.
Comitetul de Direcție asigură întocmirea în termenul prevăzut de lege a bilanțului și a contului de profit și pierderi, pe care le prezintă, cu cel puțin o lună înainte de data stabilită pentru ședința Adunării Generale, Comisiei de cenzori, iar după însușirea de către acestea, Consiliului de Administrație.
Bilanțul împreună cu raportul Comisiei de cenzori, însușite de Consiliul de Administrație vor rămâne depuse în copii la sediul central și la cel al sucursalelor, în cele 15 zile care preced întrunirea Adunării Generale, pentru a fi cercetate de acționari.
Consiliul de Administrație, în termen de 15 zile de la data ținerii Adunării Generale, depune la organele în drept copii de pe bilanț și contul de profit și pierderi. Bilanțul și contul de profit și pierderi vor fi publicate în Monitorul Oficial.
BANCA va repartiza 20% din profitul brut anual pentru constituirea de rezerve, până când fondul astfel constituit egalează capitalul, apoi maximum 10% până în momentul în care fondul a ajuns de două ori mai mare decât capitalul. După atingerea acestui nivel, alocarea de sume pentru fonduri de rezervă se va face din profitul net, pe baza hotărârii Consiliului de Administrație.
BANCA va constitui fonduri de risc pentru acoperirea eventualelor credite care nu mai pot fi recuperate, atât în profitul brut în limita a 0,5% din totalul creditelor acordate, cât și din cele nete, precum și alte fonduri.
De asemenea, din beneficiul brut se va constitui fondul de dezvoltare al BĂNCII în limitele stabilite de Adunarea Generală.
Profitul net va fi repartizat pe baza aprobării Adunării Generale, pentru:
a) plata dividendelor ce se cuvin acționarilor BĂNCII;
b) tantieme pentru administratori;
c) recompense pentru personalul BĂNCII;
d) alte destinații stabilite de Adunarea Generală.
În afară de evidențele prevăzute de lege, BANCA ține registrele stabilite prin Legea societăților comerciale.
Dispoziții finale si tranzitorii
Dizolvarea și lichidarea BĂNCII se va putea face în condițiile și în conformitate cu procedura stabilită prin Legea societăților comerciale nr. 31/1990, și a celorlalte prevederi legale în vigoare la momentul respectiv.
Pentru eventualele erori în eliberarea de mijloace bănești, neînregistrări sau înregistrări eronate în conturile clienților, BANCA răspunde numai până la limita sumei eronat eliberată, neînregistrată sau eronat înregistrată, precum și de plata penalităților ce se varsă la bugetul de stat, suportate de client, în cazurile prevăzute de lege, dacă nu se dovedește că erorile s-au produs din culpa clienților.
Răspunderea BĂNCII încetează dacă nu este sesizată, prin reclamație, până la expirarea termenului stabilit și comunicat în scris potrivit legii, titularilor de cont, de a aduce la cunoștința unităților neînregistrarea sau înregistrarea eronată a operațiunilor în conturi, reflectată în extrasul de cont sau în alte documente bancare.
Pretențiile față de BANCĂ sunt supuse prescripției prevăzute de lege.
Membrii Consiliului de Administrație, ai Comitetului de Direcție și directorii sucursalelor, filialelor și agențiilor sunt răspunzători pentru toate prejudiciile cauzate din culpa lor.
BANCA și salariații săi sunt obligați să păstreze secretul conturilor deschise clienților săi, precum și secretul tuturor operațiunilor efectuate.
Relațiile asupra operațiilor și conturilor se dau numai titularilor de conturi, organelor judecătorești și de urmărire penală, potrivit condițiilor stabilite de lege.
În perioada cât statul este acționar unic, atribuțiile legale ale Adunării Generale a Acționarilor vor fi îndeplinite de Consiliul împuterniciților Statului până la constituirea Adunării Generale a Acționarilor.
1.2. Servicii bancare la domiciliu (home banking)
Home banking definește accesul la serviciile bancare din exteriorul sediului unității bancare. Acest acces se poate realiza prin intermediul unui simplu telefon conectat la o centrală telefonica digitală sau prin intermediul unui calculator personal. Accesul la servicii bancare prin telefon (telephone banking) se realizează astfel: de la un telefon cu tastatura se formează numărul serviciului bancar telefonic, după terminarea mesajelor emise de robotul telefonic (placa voice-teller plus software-ul aferent) se tastează codul numeric personal (PIN), apoi se tastează codul operației ce se dorește a se efectua asupra contului curent. În prezent, acest tip de serviciu este întâlnit la unele bănci din țară, dar este orientat în principal spre informarea clientului privind starea conturilor sale. Clientul poate obține informațiile sub forma de voce sau fax. Accesul la servicii bancare prin intermediul unui calculator personal presupune conectarea calculatorului personal al clientului băncii prin intermediul unei linii telefonice și a unui modem la calculatorul băncii. Comunicația și accesul la serviciile bancare sunt controlate de un program specializat furnizat de bancă instalat pe calculatorul clientului. De fapt, calculatorul clientului devine un ghișeu bancar virtual. Se pot ordona plăti, se pot obține informații privind starea contului etc. Acest gen de serviciu este puțin utilizat în țara noastră.
Perspective privind sistemul bancar din țara noastră. După cum s-a văzut, în băncile românești există o mare varietate de sisteme informatice, utilizarea serviciilor bancare bazate pe tehnici moderne este încă într-un stadiu incipient. Acest lucru poate constitui un avantaj deoarece se pot alege de la bun început soluțiile optime verificate de practica bancară internațională. Implementarea metodelor moderne în activitatea bancară româneasca necesită nu doar eforturi financiare deosebite. Trebuie depășite mentalități care încă mai persistă atât la nivelul factorilor decizionali, cât și la nivelul consumatorului de servicii bancare. Din păcate, încă sunt înființate sedii noi de unități bancare care sunt dotate de la bun început cu sisteme pneumatice de transmitere a documentelor între contabilitate și casierie, în condițiile în care cu aceleași fonduri se poate achiziționa o rețea locală de calculatoare. Introducerea metodelor moderne în sistemul bancar trebuie să fie rezultanta a doua tendințe convergente. Pe de o parte, societățile bancare urmăresc creșterea operativității prin introducerea tehnicii de calcul și a metodelor moderne. Înființarea unor noi societăți bancare și extinderea ariei de cuprindere a celor existente, în condițiile în care numărul clienților – agenților economici – rămâne relativ constant, accentuează caracterul concurențial al activității bancare. Pe de alta parte, un rol determinant revine Băncii Naționale a României care are puterea oferită de lege pentru a impune societăților bancare niveluri minimale privind dotarea tehnică și serviciile bancare oferite.
1.3. Plățile prin virament
De-a lungul timpului, alături de disponibilitățile bănești propriu-zise (bani cash, bani lichizi) s-au impus tot mai mult banii de cont, banii scripturali.
În ultimele două-trei decenii s-au produs modificări substanțiale în mărimile celor două componente ale masei monetare, sensul schimbării fiind dat de creșterea ponderii operațiilor care se derulează prin intermediul banilor scripturali (prin virament). Astfel, prin transferul sumei dintr-un cont în altul, respectiv prin debitarea contului plătitor și Creditarea contului beneficiar se ajunge la o simplificare a relațiilor de plăți: Dezvoltarea băncilor a dus la generalizarea viramentelor – ca modalitate de efectuare a plăților.
Principalele caracteristici ale plăților prin virament sunt:
natura dublă, determinată pe de o parte de înregistrări în conturi bancare, iar pe de altă parte de mesaje între părți și care conțin instrucțiunile de plată;
-decalajul de timp dintre momentul inițierii și cel al finalizării operațiunii de plată;
existența unor intermediari bancari în derularea acestui tip de plăți.
Plățile prin virament utilizează instrumente si mijloace de plată emise pe suport de hârtie, magnetic sau electronic.
Ca procedeu de înfăptuire a plăților, viramentul poate fi diferit, în funcție de sensul în care se dispune și se efectuează plata. Predominant este viramentul de credit, care implică următoarea succesiune a operațiilor:
plătitorul dă ordin băncii sale să onoreze ordinul de plată către beneficiarul dat;
banca plătitoare preia suma din contul plătitorului și efectuează plata către banca beneficiarului;
banca beneficiarului înscrie suma în contul creditorului.
Deci, în mod normal, inițiativa plății aparține plătitorului. Totuși, funcționează și viramentul de debit, situație în care consimțământul plătitorului este dat, în prealabil, pe baza unei dispoziții generale pe care acesta o adresează băncii sale de a îndeplini regulat toate cerințele de plată exprimate de creditor. Viramentul de debit se practică pentru livrările de produse și servicii de interes general, cum ar fi: furnizarea de gaze, apă, electricitate, telefoane etc. În acest caz, plătitorul împuternicește creditorul pentru astfel de operațiuni. Concomitent, el solicită băncii sale aprobarea operațiunii, în al doilea rând, creditorul depune documentația la banca sa. în continuare, banca debitorului include pentru plată suma respectivă la data stabilită, iar după efectuarea plății, suma intră în contul creditorului.
În domeniul plăților, sistemul bancar trebuie să asigure așadar, mecanismele cu ajutorul cărora plata bunurilor si serviciilor să se efectueze rapid, sigur și eficient.
Având în vedere momentul efectuării plății, există plata cu anticipație, plata în momentul livrării și plata la o dată ulterioară.
Plata cu anticipație, presupunând riscul cel mai mic, este utilizată mai ales pentru stingerea obligațiilor externe, însă, în relațiile de plăți cu străinătatea, se practică și forma de plată la o dată ulterioară, utilizându-se ca instrumente de plată: incasso-ul documentar și ordinul de plată.
În țara noastră se practică atât forma de plată cu anticipație, utilizându-se frecvent cecurile, cât, și forma de plată la o dată ulterioară, folosindu-se ordinele de plată și efectele de comerț.
Pentru a asigura îndeplinirea ordinelor clienților privind efectuarea plăților, băncile trebuie să aibă relații de colaborare permanentă, care se bazează primordial pe încredere și deci, responsabilitate-onorarea obligațiilor de plată de către partenerii economici fiind o problemă vitală pentru desfășurarea activității economice.
Viramentul este operațiunea de plată/ transfer efectuată de către o banca prin care, la ordinul clientului său și în baza disponibilului existent în contul acestuia, se va realiza transferul unei sume de bani din contul clientului respectiv în contul unui beneficiar desemnat de acesta, prin debitarea contului clientului și creditarea contului beneficiarului.
La baza acestor operații stă moneda scripturală (banii de cont) reprezentând disponibilitățile bănești aflate în conturile bancare, bani care circulă între aceste conturi prin intermediul operațiunilor de virament. Aceste monede scripturale pot fi atât monede naționale (în cazul țării noastre lei) cât și monede ale altor state (valuta sau devizele) fapt care determină o delimitare a banilor de cont și un plasament al acestora în conturi diferite: conturi în lei și conturi în valută (devize).
Din acest motiv, în funcție de moneda în care se realizează viramentul, se vor întâlni viramente în lei și viramente în valută.
O particularitate a viramentului este reprezentată de plasamentul băncilor care formează circuitul dintre ordonator și beneficiar. Dacă viramentul se realizează între bănci din același stat se poate vorbi despre un virament național (care poate fi intre filialele, sucursalele aceleași bănci sau între bănci diferite care implica transfer de fonduri între acestea) sau, dacă se realizează între bănci plasate în state diferite se poate vorbi despre un virament internațional (care are același specific cu deosebirea că implică un transfer internațional al fondurilor).
Viramentele naționale se realizează prin intermediul mijloacelor de comunicare interbancară, urmând proceduri stricte specifice structurii bancare naționale dar și particularităților operaționale ale fiecărei bănci în parte, modul de realizare al acestora fiind clasic (pe o durata de 1 – 2 zile) sau tip telex (virament realizat în ziua curentă înaintării ordinului de plată, etc. de către plătitor). Există unele particularități atunci când se folosește plata în valută în special în tarile cu retenție valutară (cum este și cazul României) unde se urmează anumite proceduri specifice, de cele mai multe ori impuse de norme legislative naționale sau de instrucțiuni BNR. Aceste proceduri afectează în special modul de realizare a plaților in valută deoarece există conturi în monedă naționala și conturi în valută, urmărindu-se la efectuarea plății dacă există sau nu disponibilul necesar și, totodată, dacă este posibil ca banca sa achiziționeze în baza disponibilităților în moneda naționala necesarul de devize solicitat pentru efectuarea viramentului.
Cele mai multe viramente internaționale se realizează în cazul operațiunilor de comerț exterior, când este necesară realizarea unei plăți de către importator. Transferul fondurilor se realizează prin diferite metode având la bază diverse rațiuni care nu fac obiectul acestei prezentări. Trebuie reținut doar faptul ca viramentul propriu-zis se realizează de cele mai multe ori înainte de transferul efectiv de fonduri, la bază stând acorduri bancare sau naționale care dau girul de garanție și garantare al transferului de fonduri. În plus se poate aminti de faptul că, în dorința de a elimina neajunsurile modalităților clasice de transfer postă, telex, etc. și pentru a răspunde exigentelor de rapiditate, confidențialitate și securitate impuse de tranzacțiile internaționale s-a înființat (în mai 1973) societatea "SWIFT" (Society for Worldwide Interbank Financial Telecomunication) care este o rețea de comunicare interbancara internaționala pe suport electronic.
SWIFT este conceput intr-o maniera modulara si cuprinde trei niveluri de funcționare: 1. banca cu terminalul propriu, 2. cumulatorul național cu rol de nod de concentrare a informațiilor (la nivel național) și 3. centrul de comutare reprezentat de un releu în sistem SWIFT care asigură cuplarea la rețea a țărilor care sunt arondate. Există, la acest moment, 3 astfel de centre de comutare:
in SUA, având arondate țări din America de Nord, America de Sud si Extremul Orient;
în Belgia (Bruxelles), având arondate țări europene ca Franța, Italia, Belgia, Spania, Danemarca precum și Israel;
în Olanda (Zoeterwonde) unde exista două comutatoare, unul pentru Germania, Austria, Elvetia, Ungaria și altul pentru Marea Britanie, Țările Scandinave, Olanda, Grecia, Portugalia, s.a.
Pentru realizarea de transferuri SWIFT, cumpărătorul (debitorul plății) realizează operațiile uzuale oricărei plăți către un beneficiar. Rolul principal in acest mod de transfer îl are banca care lansează mesaje codificate în rețeaua interbancara solicitând asemenea oricărui alt procedeu executarea viramentului către banca beneficiarului, realizarea viramentului fiind efectuată în 20 de minute (pocedura normală) sau 5 minute (procedura de urgență).
1.4. Ordinul de plată
Ordinul de plată este un instrument de plată și decontare utilizat pentru stingerea unor obligații devenite exigibile. Altfel spus, o dispoziție dată de un client băncii sale în scopul efectuării unei plăți în favoarea unei terțe persoane. Așadar, operațiunea de virament presupune o stare mutuală de credit între banca ce execută operația și clienții săi care-și au cont deschis la respectiva bancă și disponibil în cont.
Două sunt cauzele care generează raporturi de credit între bancă și clienții săi:
când clienții au un depozit într-un cont al lor la banca cu care lucrează;
când clienții, fără a avea un depozit la bancă, primesc de la aceasta un credit pe care-l pot utiliza pentru efectuarea plăților.
Fiecare dintre aceste cauze determină banca să deschidă clientului său un cont și să-i înmâneze un carnet de cecuri prin care titularul contului poate da ordin asupra disponibilului său din cont. Acest ordin poate fi executat sub două forme:
banca plătește în numerar suma înscrisă;
banca micșorează disponibilul celui ce dă ordinul și-1 mărește pe al aceluia în favoarea căruia este emis ordinul, fără a se produce nici o mișcare de monedă efectivă.
Această ultimă operațiune este denumită operațiune de virament și ea face să se stingă contabil și juridic o obligație sau o creanță între două persoane.
Așa cum se cunoaște, contul curent crește cu depunerile titularului contului și cu încasările pe care banca le face pentru clientul său și descrește cu toate plățile pe care banca le operează în cont, în baza ordinelor primite de la titular.
Operațiunea de debitare a contului bancar al titularului se realizează printr-un înscris numit ordin de virament. În practică, operațiile de virament se execută pe baza cecurilor de virament, ordinelor de plată, dispozițiilor de încasare ș.a.
Ordinul de plată este o dispoziție necondiționată dată de către emitent băncii la care-și are deschis contul de a pune la dispoziția unui beneficiar o anumită sumă de bani. Practic, în acest mod banca se substituie debitorului, ceea ce face ca operațiunea să apară sub forma unei delegații. De aici decurg o serie de raporturi juridice, respectiv:
raporturi între debitor și bancă; .
raporturi între debitor și beneficiar;
raporturi între bancă și beneficiar.
Procedura de executare a viramentului este următoarea: în baza ordinului de plată primit banca micșorează disponibilul celui ce dă ordinul și mărește disponibilul aceluia în favoarea căruia este emis ordinul.
Confirmarea executării operațiunii se face prin remiterea de către bancă, atât plătitorului cât și beneficiarului, a unui înscris numit extras de cont.
Un ordin de plată trebuie să conțină următoarele elemente obligatorii:
ordinul necondiționat de a plăti o anumită sumă de bani;
numele beneficiarului și numărul de cont al acestuia, deschis la banca destinatară;
numele plătitorului și numărul contului deschis acestuia la banca inițiatoare;
denumirea băncii inițiatoare și a băncii destinatare;
elemente de natură să permită autentificarea emitentului de către banca inițiatoare.
Prezentăm în continuare principalele etape privind circulația unui ordin de plată;
1. firma "A" încheie un contract cu firma "B", prestatoare de servicii, contract cu plata prin ordin de plată;
2. în acest scop firma "A" emite un ordin de plată pe care îl prezintă băncii la care are deschis contul și care este banca inițiatoare;
3. aceasta efectuează operațiuni de recepție, autentificare, acceptare și executare a ordinului de plată primit» după care îl remite băncii destinatare;
4. banca destinatară (a beneficiarului) acceptă ordinul de plată și creditează contul clientului său cu suma înscrisă pe ordinul de plată primit. Astfel, transferul – credit este finalizat, unitatea prestatoare recuperându-și contravaloarea serviciilor efectuate.
În cazul în care operațiunea de transfer nu se finalizează, banca inițiatoare are obligația să Deturneze plătitorului suma primită de la acesta în baza ordinului de plată. Dacă la restituirea sumei apar din partea plătitorului penalizări (dobânzi de întârziere), ele vor fi achitate de bancă pentru intervalul cuprins între începutul perioadei de execuție și data restituirii sumei.
În situația când transferul este finalizat, dar banca destinatară nu execută ordinul de plată în termenul prevăzut, ea are obligația față de beneficiar de a-i plăti dobânzi de întârziere, calculate la suma înscrisă în ordinul de plată.
Există cinci circuite pe care poate să le urmeze ordinul de plată, în funcție de localitățile în care își au sediul banca plătitorului si respectiv, banca beneficiarului sumei specificată în instrumentul de plată. Atunci când transmiterea sumelor la distanță între sediile băncilor respective se realizează prin sistemul clasic pe suport hârtie (letric, telex, fax), executarea ordinului de plată presupune un decalaj de timp între momentul debitării contului plătitorului și momentul creditării contului beneficiarului.
În situația în care ordinul de plată este emis pe suport magnetic sau electronic și se utilizează sistemul modern de transmitere cu ajutorul calculatoarelor electronice interconectate, se elimină decalajul de timp pe care-1 presupune sistemul clasic, înregistrarea sumei având loc, aproape concomitent, atât în debitul contului plătitorului cât și în creditul contului beneficiarului.
CAPITOLUL II
2.1. Tehnici criptografice.
2.1.1. Generalități privind tehnicile criptografice
Acest termen e în general utilizat pentru a face referire la un set de instrumente matematice și logice destinate a asigura securitatea și protecția informației vehiculat în cadrul unui sistem. Între cele mai folosite astfel de tehnologii se pot enumera criptarea, funcțiile de dispersie criptografice, codurile de autentificare mesaj, semnăturile digitale și certificarea electronică. Securitatea și protecția furnizării de tehnologiile respective se asigură la nivel logic prin intermediul următorului set de servicii de securitate:
Confidențialitatea (este furnizată prin intermediul criptării) – reprezintă restricționarea prin criptare a cunoașterii informațiilor dintr-un sistem numai la părțile implicate (autorizate). Se previne astfel consultarea și modificarea de către entități neautorizate (utilizatori sau programe) a informațiilor în cauză. Confidențialitatea se poate asigura atât pentru mesajele transmise cât și pentru datele stocate în sistem.
Autentificarea. Autentificarea entităților corespondente – reprezintă procesul asigurării că o entitate este cea ce se declară a fi. În cadrul acestui proces se parcurg două etape:
identificarea sigură a entității;
verificarea identității afirmate.
Identificarea e reprezentată de recunoașterea unei informații unice asociate entității (un nr., un șir de caractere, etc.) numită identificarea unității și pe care aceasta o declară. Prin verificarea identității declarate (a identificatorului) se stabilește dacă entitatea este în fapt componenta care se pretinde a fi.
Autentificarea mesajelor are ca scop verificarea sursei și conținutului original al mesajelor schimbate între entitățile comunicante. Acest serviciu de securitate verifică dacă mesajul provine de la emițătorul autentic, dacă conținutul său nu a fost schimbat, dacă mesajul este livrat receptorului autorizat și el nu a mai fost recepționat deja, dacă mesajul este recepționat în aceeași secvență în care a fost transmis.
Autentificarea este furnizată prin funcții de dispersie criptografice, coduri de autentificare mesaj și semnături digitale.
Non repudierea – Scopul său este acela de a colecta, întreține, a face disponibil și valida dovezi referitoare la datele transferate între entitățile implicate într-un schimb, dovezi ce nu pot fi negate. În acest fel se pot stabili obligațiile legale ale părților respective și rezolvarea disputelor dintre acestea cu privire la autenticitatea unui mesaj, în speță prevenirea ca emițătorul mesajului să nege că s-ar afla la originea acestuia.
Tehnicile criptografice pentru asigurarea acestui serviciu trebuie să fie suficient de puternice astfel încât autenticitatea originii mesajului să poată fi dovedită unui terț cu rol de judecător-arbitru. Se mai apelează și la alte servicii sistem cum ar fi datările.
Integritatea – Acest serviciu asigură că datele vehiculate în cadrul unui sistem nu au fost alterate sau distruse de o manieră neautorizată. Integritatea este abilitatea de a determina dacă datele recepționate sunt aceleași cu cele transmise, iar mecanismul destinat efectuării acestei verificări trebuie să asigure că orice diferență poate fi detectată. În practica integrității și autentificării datele sunt legate între ele deoarece sunt cerute simultan și utilizează aceleași mecanisme. Ca urmare chiar dacă există certitudinea că datele provin de la sursa declarată, acest lucru nu e de mare folos dacă ele au putut fi modificate fără autorizare. Invers, știind că datele au fost transmise fără a fi modificate ele nu au utilitate decât dacă există certitudinea că ele provin de la sursa declarată. Integritatea e asigurată prin intermediul funcțiilor de dispersie criptografic, coduri de autentificare mesaj și semnături digitale.
Criptarea este o tehnică criptografică cu rolul de a furniza prin intermediul mecanismelor de securitate sub care e implementată (criptosisteme), confidențialitate atât datelor transmise cât și celor stocate în sistem. Destinatarul asigură securitatea și protecția informației împotriva accesului neautorizat. Ea permite realizarea de comunicații secrete peste un mediu de transmisie nesigur.
2.1.2. Criptosisteme
Un criptosistem este un mecanism de securitate ce permite realizarea unei comunicații secrete între două entități. Tipic, el constă într-o pereche de funcții, una de criptare, aplicată de emițătorul mesajului și una de decriptare aplicată de receptorul acesteia. Pentru a transmite un mesaj emițătorul aplică asupra acestuia funcția de criptare și expediază rezultatul numit mesaj criptat sau criptogramă. După ce a recepționat mesajul criptat receptorul aplică funcția de decriptare și obține mesajul original numit mesaj clar.
Pentru ca schema anterioară să furnizeze o comunicare secretă entitățile comunicante trebuie să cunoască un element ce nu este cunoscut unei entități adverse, altfel aceasta poate obține mesajul clar la fel ca și receptorul autorizat, prin decriptarea mesajului criptat. Această informație suplimentară, secretă, poate lua forma fie a funcției de decriptare înseși, fie a anumitor parametri și/sau intrări auxiliare utilizate de către ambele funcții, sau numai de către funcția de decriptare. Numim această informație suplimentară cheie. Ținând cont de cele afirmate putem defini formal un criptosistem ca fiind un cvintet (M,C,K,E,D) ce satisface următoarele proprietăți:
M e o mulțime finită de mesaje clare posibile;
C e o mulțime finită de mesaje criptate posibile;
K e o mulțime finită de chei posibile;
Pentru orice () cheie kK există o funcție de criptare EkE și o funcție de decriptare corespondentă DkD. Fiecare din cele două funcții Ek și Dk definite pe C cu valori în M satisfac relația Dk (Ek(M))=M pentru orice mesaj clar MM. Este evident că funcția de criptare Ek trebuie să fie injectivă adică valorile criptate a două mesaje clare diferite să nu fie egale. Altfel procedura de decriptare nu se va putera realiza fără ambiguitate.
Criterii de clasificare a criptosistemelor
1) Modul în care este tratat mesajul clar. Criptosistemele se împart în două categorii:
Criptosisteme cu criptare secvențială – Tratează mesajul clar pe porțiuni mici (biți sau caractere), generând o succesiune pseudoaleatoare de simboluri. Securitatea lor se bazează pe schimbarea funcției de criptare pentru fiecare simbol într-o manieră dificil de prevăzut.
Criptosisteme cu criptare bloc – funcționează într-un mod pur convențional cu blocuri mari de mesaj clar, astfel că o modificare în blocul de intrare determină o modificare majoră în cel rezultat la ieșire. Această proprietate se numește propagarea erorii.
2) După tipul cheilor folosite:
Criptosisteme simetrice (cu cheie secretă). Cheile k și k` de criptare și decriptare sunt identice sau se pot deduce ușor una din cealaltă.
Criterii asimetrice (cu cheie publică). k și k` sunt diferite și imposibil de dedus una din alta prin calcule.
2.1.3. Criptosisteme cu cheie publică
Fac parte din categoria celor de tip asimetric. Ideea ce stă la baza lor → pentru criptare se folosește o cheie asociată unui utilizator, cheie ce e făcută publică și care poate fi folosită de către toți ceilalți utilizatori pentru criptarea mesajelor ce îi sunt adresate. În schimb cheia de decriptare, diferită de prima (asimetrie) e păstrată secretă, ea conferind numai posesorului ei posibilitatea de a de decripta mesajele ce îi sunt adresate și au fost criptate cu cheia sa publică.
Cele două chei, publică (e) și secretă (d) sunt generate de către receptorul mesajului, iar dezvăluirea lui e nu trebuie să compromită pe d ceea ce înseamnă că obținerea cheii secrete din cea publică este imposibilă sau presupune un consum prohibitiv de resurse.
Comunicația între cele două entități A și B, receptor și destinatar se desfășoară conform următorului protocol:
folosim cheia publică a receptorului (eB). A calculează din mesajul clar M mesajul criptat C=EeB(M).
A expediază mesajul criptat C lui B
B decriptează mesajul C recepționat utilizând cheia sa secretă (dB) și determină mesajul în clar M=DAD(c).
O altă practică de implementare a acestui tip de criptosistem pleacă de la ideea utilizării unor funcții greu inversabile (cu sens unic). O funcție e greu de inversat dacă e ușor să se calculeze y din x (y=f(x)) există inversa funcției, pentru aproape toate valorile y din codomeniu e imposibil computațional să se calculeze x=f-1(y). Aceste funcții își au originea în problemele dificil de rezolvat la nivelul cunoștințelor matematice de azi, cum sunt factorizarea unui produs de numere foarte mari, problema rucsacului, etc. Exemplu de criptosistem: RSA (Rivest Shamir Adelman).
O analiză comparativă între cele două clase de criptosisteme trebuie să plece de la gradul de satisfacere a două tipuri de cerințe și anume:
cerințe de securitate;
cerințe de cost.
O primă cerință de securitate se referă la faptul că tăria criptografică a criptosistemului în cauză să nu depindă pe de o parte în mod exclusiv de complexitatea operațiunilor implementate și pe de altă parte de secretul algoritmului. Cerința respectivă este critică, un criptosistem ce își bazează tăria criptografică pe secretul structurii sale fiind sortit deconspirării.
A 2-a cerință pe care este de dorit să se bazeze tăria oricărui criptosistem o constituie lungimea cheii de criptare. Cu cât e mai lungă cu atât securitatea e mai bună și efortul necesar unei criptanalize e mai mare. Din acest punct de vedere cea mai mare parte a criptosistemelor cu cheie secretă au o lungime a cheii dată, lucru impus de însăși structura internă a lor. Criptosistemele cu cheie publică, având o lungime a cheii variabilă îndeplinesc această cerință de securitate dovedind o flexibilitate mare.
La cerințele de cost o primă cerință se referă la nr.-ul și lungimea mesajelor necesare a fi schimbate între entitățile ce folosesc pentru secretizarea comunicațiilor criptosisteme din cele două clase. Din analiza criptosistemelor reprezentative se remarcă faptul că nr.-ul de mesaje și lungimea lor sunt mult mai mari în cadrul criptosistemelor bazate pe chei publice decât în cadrul celor bazate pe cheie secretă rezultând un trafic mai mare în cadrul criptosistemelor cu cheie publică decât în cadrul celor cu cheie secretă.
În concluzie: din acest punct de vedere criptosistemele cu cheie secretă sunt mai eficace și mai rapide (îndeosebi cele hardware) decât cele cu chei publică, făcându-le ideale pentru criptarea fișierelor. Deși acest lucru este important nu trebuie neglijată cea de-a doua cerință de cost: ușurința în distribuirea cheilor. Dacă criptosistemele cu cheie secretă necesită înaintea inițierii oricărei comunicații secretizate distribuirea prin intermediul unui canal sigur a cheilor de criptare-decriptare, criptosistemele cu cheie publică elimină acest impediment major. La acest avantaj se adaugă și facilități de autentificare și de semnătură digitală oferite, ele fiind ideale din acest punct de vedere.
2.2. Conceptul de semnătură digitală.
2.2.1. Generalități privind semnătura digitală
În mod tradițional semnăturile olografe (de pe documente) servesc la autentificarea acestora fiind utilizate în dovedirea identității semnatarului și ca mijloc de exprimare a acordului acestuia cu conținutul documentului. O astfel de semnătură angajează de regulă responsabilitatea semnatarului și ptr a fi valabilă ea trebuie să asigure următoarele: să nu poată fi falsificată, reutilizată, autentică și să nu poată să fie renegată. Necesitatea utilizării semnăturii digitale a apărut odată cu introducerea în mediile de afaceri a comunicației prin intermediul calculatoarelor, când s-a pus problema semnării unor documente exprimate sub forma mesajelor electronice și transmiterea semnăturilor în rețelele de calcul. Deși rolul și cerințele pe care trebuie să le îndeplinească o semnătură digitală sunt aceleași ca cele ale unei semnături convenționale, între ele există diferențe fundamentale. O primă diferență o constituie noțiunea de semnare a unui document. Astfel în timp ce o semnătură convențională e atașată fizic documentului semnat acest lucru nu poate fi realizat de aceeași manieră pentru o semnătură digitală, deoarece spre deosebire de o semnătură convențională o semnătură digitală se prezintă fie ca o versiune transformată a mesajului clar complet (cu document în formă electronică), și apoi fie ca o valoare suplimentară distinctă ce face pereche cu mesajul respectiv transmis. Prin urmare procedeul de semnare trebuie într-un anume fel să lipească semnătura la mesajul electronic. O a doua diferență este cea legată de verificarea semnăturii. O semnătură convențională e autentificată prin compararea sa cu o alta care a fost certificată. Această metodă e puțin fiabilă deoarece semnătura unei persoane se poate imita ușor. O semnătură digitală poate fi verificată de către oricine cunoaște informația publică de verificare, identificându-se astfel emițătorul mesajului la care e atașată. O altă diferență fundamentală între semnătura convențională și cea digitală e că orice copie a unui document electronic e identificată cu originalul, spre deosebire de cea semnată pe hârtie care poate fi deosebită de original. Se impune luarea de măsuri pentru ca un document electronic semnat să nu poată fi reutilizat. De asemenea în timp ce semnătura unei persoane e constantă (cea de mână), una digitală depinde într-o manieră complexă de fiecare caracter al mesajului astfel încât modificarea acestuia să fie imposibil de făcut fără ca semnătura să rămână neschimbată. Se asigură astfel integritatea mesajului prevenindu-se schimbarea conținutului său și posibilitatea ca semnătura să fie mutată de la un mesaj la altul. Acest lucru necesită ca mărimea câmpului semnăturii să fie suficient de mare a.î. căutarea tuturor mesajelor posibile pentru o semnătură dată să fie computațional dificilă.
O semnătură digitală poate fi calculată de către emițătorul mesajului căruia i se atașează pe baza unei informații secrete cunoscute numai de către el. Informația trebuie să fie în legătură cu o informație publică a cărei cunoaștere de către receptor să-i permită acestuia verificarea semnăturii, în acest fel se asigură non repudierea originii- prevenirea negării de către emițător ca fiind la originea expedierii. Emițătorul va fi încrezător în faptul că receptorul nu va putea să schimbe nici un bit al mesajului fără a altera semnătura.
Semnătura electronică extinsă reprezintă acea semnătură electronică, care îndeplinește cumulativ următoarele condiții:
a. este legată în mod unic de semnatar;
b. asigură identificarea semnatarului;
c. este creată prin mijloace controlate exclusiv de către semnatar;
d. este legată de înscrisul electronic la care se raportează în așa fel încât orice modificare ulterioară a acestuia este identificabilă.
Certificatul reprezintă un înscris în format electronic care cuprinde atestarea legăturii ce există între o persoană și datele de verificare a semnăturii electronice și care confirmă identitatea acelei persoane.
Mecanismul securizat de creare a semnăturii reprezintă acel mecanism de creare a semnăturii care îndeplinește cumulativ următoarele condiții:
· datele de creare a semnăturii, utilizate pentru generarea semnăturii, nu pot apărea practic decât o singură dată și confidențialitatea acestora poate fi asigurată;
· datele de creare a semnăturii, utilizate pentru generarea semnăturii, nu pot fi deduse și semnătura este protejată împotriva falsificării prin mijloacele tehnice disponibile la momentul respectiv;
· datele de creare a semnăturii pot fi protejate în mod efectiv de către semnatar împotriva utilizării acestora de către persoane neautorizate, să nu modifice înscrisul electronic ce trebuie semnat și nici să nu împiedice ca acesta să fie prezentat semnatarului înainte de finalizarea procesului de semnare.
Datele de creare a semnăturii reprezintă orice date în format electronic cu caracter de unicitate, inclusiv coduri sau chei criptografice private, care sunt folosite pentru crearea unei semnături electronice.
Datele de verificare a semnăturii reprezintă orice date în format electronic, inclusiv coduri sau chei criptografice publice, care sunt folosite în scopul verificării unei semnături electronice.
Ultimele două definiții scot în evidență faptul că metodele de criptare cu cheie asimetrică sunt puse la dispoziția realizării efective a semnăturii electronice.
Criptografia cu cheie asimetrică sau cu cheie publică se folosește de o pereche de chei – una privată la criptarea documentului și alta publică la decriptarea documentului. Prin această metodă de criptare securitatea datelor sporește, deoarece cheia privată care asigură identitatea semnatarului nu mai trebuie distribuită destinatarului, decriptarea realizându-se printr-o cheie publică aflată într-o relație matematică cu cheia privată. Cu alte cuvinte semnătura se realizează prin mijloace aflate exclusiv la îndemâna titularului semnatar, iar această semnătură se poate verifica prin mijloace aflate la îndemâna unui public mai larg – acela care este autorizat a citi documentul semnat electronic.
Importanța certificatelor digitale apare pregnant în asigurarea unei mai bune securități în purtarea corespondenței. În condițiile circulației libere a cheilor publice există posibilitatea de fraudă. Cineva ar putea să plaseze o cheie falsă cu numele și identitatea destinatarului vizat. Datele criptate – și interceptate – de posesorul adevărat al cheii mincinoase sunt acum în alte mâini decât cele ale destinatarului vizat.
În materie de chei publice, este vitală asigurarea că cheia publică cu care se criptează datele este de fapt cheia publică a destinatarului vizat și nu una falsă. Există posibilitatea de criptare a datelor cu acele chei care au fost înmânate fizic. Dar în eventualitatea schimbului de informații cu persoane care nu au fost în prealabil cunoscute, se pune în mod serios problema autenticității cheii.
Certificatele digitale au menirea de a simplifica sarcina de a stabili dacă o cheie publică aparține în realitate posesorului ei. Un certificat digital este constituit din datele care au aceleași finalități ca și în cazul unui certificat fizic. Un certificat digital este informația inclusă odată cu cheia publică a unei persoane care permite altora să verifice originalitatea sau validitatea cheii. Acesta este emis de o autoritate de certificare care are atribuții de atestare a legăturii dintre cheia publică și titularul ei, precum și drepturi de utilizare sau după caz, anumite restricții de utilizare a semnăturii electronice.
2.2.2. Procedee de obținere a semnăturilor digitale
Pentru obținerea unei semnături digitale în practică se utilizează 2 procedee de bază:
1. primul constă în obținerea unei semnături prin transformarea a însăși mesajului clar ce se dorește a fi transmis. Pentru aceasta se folosește de regulă un criptosistem cu cheie publică în cadrul căruia se inversează procesul de aplicare a celor 2 chei.
Ca urmare, pentru crearea unui mesaj semnat notat cu S emițătorul A va folosi transformatorul de decriptare D cu cheia sa secretă dA.
La rândul său receptorul B al mesajului semnat va verifica originea autentică a acestuia și integritatea prin decodificarea sa utilizând transformarea de criptare E cu cheia publică CA a emițătorului.
Dacă rezultatul este un mesaj clar posibil (mesaj semnificativ) mecanismul de semnătură a funcționat bine și semnătura e validă fiind acceptată.
Procedeul de scris e ilustrat în figură:
mesaj în clar M semnătură S=DdA(M) mesaj reconstituit M=EcA(S)
Argumentul doveditor al validității semnăturii îl reprezintă faptul că numai posesia cheii secrete dA permite calculul unui mesaj S a cărui transformare cu ajutorul cheii publice CA produce un mesaj semnificativ.
Eficacitatea acestui procedeu se bazează pe un anumit număr de ipoteză.
În primul rând se presupune că cheia secretă a fost într-adevăr păstrată secretă de emițător deoarece în caz contrar o entitate adversă va putea să semneze mesaje substituindu-se astfel emițătorului original.
2. identitatea emițătorului și a cheii sale publice, se presupune a fi autentice, certificarea acestei autenticități fiind făcută de preferință de către o autoritate de certificare. Dacă o entitate adversă va reuși să facă un destinatar să accepte o cheie publică falsă (a cărei cheie secretă corespondentă o cunoaște) atunci ea va putea să falsifice mesaje cu o semnătură care va apărea ca fiind validă.
O altă ipoteză este că orice modificare asupra mesajului semnat S produce la destinatar după aplicarea cheii publice o ieșire inacceptabilă pe care acesta va trebui să o distingă de un mesaj semnificativ. E important ca nimeni să nu poată deteriora prin calcul modificări în mesajul clar lăsând semnătura neschimbată.
Aceasta presupune pe de o parte că semnătura trebuie să depindă de toți biții unui mesaj clar pentru ca ea să fie inalterabilă, iar pe de altă parte se impune necesitatea existenței unei redundanțe suficiente în mesajul clar (ca parte integrantă a acestuia) pentru ca probabilitatea de acceptare a unui mesaj aleatoriu să fie foarte redusă.
Redundanța e esențială deoarece în toată procedura de semnare verificarea depinde de faptul că o singură porțiune foarte mică din șirul de biți receptați este susceptibilă de a fi acceptată ca și mesaj valid.
Securitatea procedeului se bazează pe presupunerea că problema computațională ce constituie suportul criptosistemelor cu cheie publică folosite este computațional dificilă.
În figură am presupus că procesul de semnare se aplică unui mesaj scurt văzut ca un singur bloc.
Atunci când trebuie semnat un mesaj mai lung procedeul bazat exclusiv pe utilizarea criptosistemelor cu cheie publică devine ineficient datorită vitezei scăzute a acestora. Dacă se încearcă totuși tratarea mesajului pe porțiuni (bloc după bloc) prin acest procedeu apare riscul ca o entitate adversă să schimbe ordinea blocurilor semnate semnăturile rămânând valide în continuare.
Pentru a preîntâmpina această situație se preferă utilizarea celui de al II-lea procedeu de obținere ce presupune calculul și utilizarea unei semnături digitale ce ia forma unei valori separate adăugate mesajului în clar.
Redundanța necesară mesajului respectiv pentru ca o falsificare să poată fi detectată cu o mare probabilitate de destinatar e reprezentată de semnătura ce se adaugă mesajului respectiv. Utilizarea celui de al II-lea procedeu este ilustrată în figură:
h(M) semnătură h(M)
==> Da/Nu
A B
Mesaj
M M
Se aplică asupra mesajului M în totalitatea sa o funcție de dispersie criptografică h. Rezumatul obținut H=h(M) servește apoi ca intrare pentru un criptosistem cu cheie publică ce permite obținerea semnăturii mesajului întreg prin aplicarea transformării secrete a emițătorului.
Se expediază destinatarului mesajul în clar și semnătura. După recepție destinatarul trece la verificarea semnăturii primite. Pentru aceasta aplică asupra semnăturii cheia publică a expeditorului eA iar asupra mesajului M funcția de dispersie criptografică comparând rezumatele obținute.
În caz de coincid semnătura și mesajul sunt acceptate.
Funcția h trebuie să fie făcută publică.
Tăria procedeului anterior depinde în mod esențial de inabilitatea unei entități adverse de a construi un mesaj care se potrivește cu o valoare a rezumatului dată în caz contrar putându-se genera o aceeași semnătură pentru 2 mesaje diferite.
Observăm că regimul juridic este identic cu cel al probelor prin înscrisuri, lucru oarecum firesc în condițiile admisibilității documentelor în format electronic ca probe în justiție.
Proiectul de lege privind semnătura electronică este inspirat din Directiva Parlamentului și a Consiliului European 1999/93/EC ce tratează aceeași materie. Acesta conține definițiile unor noțiuni folosite mai sus la descrierea regimului juridic al înscrisurilor în format electronic.
2.3. Principii de funcționare a aplicațiilor realizate pe baza modelului client-server
Însăși numele acestei tehnologii de dezvoltare a aplicațiilor, client-server, ne indică faptul că avem de a face cu două entități distincte care comunică între ele, una îndeplinind cererile celeilalte. Cele două entități trebuie să poată lucra separat, fie pe calculatoare distincte, fie ca două procese independente în cazul în care este disponibil un sistem de operare multiproces. Unul dintre procese, procesul server, rulează în permanență în gol, așteptând să primească sarcini de executat. Un server poate în general deservi mai multe procese client fie direct, fie prin intermediul unor procese fii create câte unul pentru fiecare client în parte. Procesul server trebuie să poată să fie găsit întotdeauna la aceeași adresă de către clienți (adică pe același calculator, la aceeași adresă IP), pentru ca aceștia să îi poată comunica cererile. Procesele clienți însă, pot lansa cererile de oriunde din rețea. Este, dacă dorit, o situație asemănătoare cu aceea a unui vânzător de dulciuri care poate fi găsit în permanentă în magazinul său aflat mereu în același oraș, pe aceeași stradă. Clienții pot fi oricare, și oricât de mulți atâta timp cât știu adresa vânzătorului și nu depășesc capacitatea de deservire a acestuia.
Desigur, între clienți si server trebuie să existe un limbaj comun în așa fel încât cererile adresate serverului să poată fi ușor înțelese și rezolvate de către acesta. De multe ori, rezolvarea cererilor înseamnă returnarea unui set de date către client, selectat după dorințele acestuia. Serverul de fișiere acceptă cererile de date venite de la stații și le prelucrează. Să luăm exemplul unui program lucrând cu fișiere memorate în rețea, și care dorește să prelucreze datele dintr-un fișier DBF aflat pe un server. Să presupunem că programul nu vrea să prelucreze toate înregistrările din fișierul DBF, ci doar acelea care îndeplinesc o anumită condiție: au un câmp logic pe valoarea adevărat sau au o dată de înregistrare nu mai veche de o lună, etc. Care este soluția clasică? Aceea de a deschide fișierul de pe server si de a-i cere acestuia să transmită rând pe rând toate înregistrările aflate în fișier. Pe măsură ce aceste înregistrări sosesc la client, acestea sunt verificate dacă îndeplinesc condiția dată și, în caz de succes, sunt prelucrate. Dezavantajul unei astfel de abordări este acela că toate înregistrările, indiferent dacă îndeplinesc sau nu condiția dorită, sunt transferate către client. O idee mai bună ar fi aceea ca împreună cu cererea, să-i fie comunicată serverului și condiția care trebuie îndeplinită de către înregistrări pentru a putea fi prelucrate. În acest caz, serverul ar putea transmite spre client doar acele înregistrări care îndeplinesc condiția. În acest fel, traficul pe rețea este mult mai mic. În plus, clienții (în număr mare de obicei) nu trebuie să conțină în interior algoritmi sofisticați de selectare a înregistrărilor care îndeplinesc o anumită condiție. Acești algoritmi sunt memorați o singură dată, în interiorul serverului. Mai mult decât atât, datele originale sunt mereu protejate de server si memorate în orice format consideră serverul că este mai eficient. Clienții trebuie să cunoască doar formatul în care sosesc datele pe rețea, un format în general mult mai simplu.
Acestea sunt ideile care stau la baza unei arhitecturi client-server. Clienții comunică într-un limbaj standard cererile lor către server, iar acesta le execută indiferent dacă este vorba de cereri de selectare de date sau de actualizare a acestora. Într-un mod asemănător lucrează FoxPro atunci când lansează o cerere SQL-SELECT către un server SQL. Rezultatul cererii este memorat într-o tabelă temporară în memorie si poate fi prelucrat în același mod ca și o tabelă normală. Datele din memorie sunt o copie a acelora de pe server, modificarea lor duce doar opțional și la modificarea originalelor. Limbajul SQL în sine este un limbaj standard, des utilizat pentru comunicația dintre un server de baze de date și clienții acestuia.
Comunicația între aplicații se face folosind protocolul TCP/IP. Serverul folosește un anumit port TCP/IP la care îl pot căuta clienții. Un lucru interesant de observat este că aplicația client nu stochează nici un fel de date în tabele.. Cunoașterea modului de memorare a datelor este un privilegiu al aplicației server.
Aplicația client comunică serverului cererile sale printr-un soclu cu conexiune, sub formă de mesaje. Mesajele sunt de lungime variabilă. Serverul analizează cererea si comunică înapoi datele solicitate.
Pornim de la premisa unei rețele de calculatoare LAN,WAN și a unor sisteme de calcul care permit comunicarea simultană a mai multor entități software ce rulează pe ele (majoritatea permit acest lucru) cu rețeaua și între ele, local. Oricare dintre aceste entități poate fi numit server (software) daca este in măsură să comunice la un nivel superior de negociere cu o alta entitate, satisfăcându-i acesteia din urma o cerere rezultată în urma negocierii/discuției prealabile. Entitatea care face cererea se va numi client iar discuția o vom numi protocol server-client. Astfel se prezintă simplificat modelul server-client în general și în particular în cadrul unei rețele de calculatoare. Protocolul va avea loc prin intermediul rețelei, și în acest caz vorbim de model server-client în rețea sau chiar local (pe aceeași mașina rezidă și serverul și clientul și comunică prin mecanismele oferite de către sistemul de operare al mașinii respective; de remarcat că am pornit în acest al doilea caz de la premisa posibilității unei multiprocesări facilitată de calculatoarele din acea rețea) În cadrul rețelei Internet acest model stă la baza majorității protocoalelor implementate la nivel superior și înțelegerea lui duce la eliminarea multor confuzii și neînțelegeri în ceea ce privește rețeaua și ceea ce se 'întâmplă' pe ea. Un exemplu simplu ar fi mecanismul prin care se realizează conectarea in mod terminal pe alt calculator. Programul local (telnet) este un client care în faza inițiala începe o conversație cu un alt program rezident/activ (serverul) pe mașina destinație, stabilind parametrii de baza ai conexiunii.(felul terminalului etc.) După determinarea de ambele părți a unor variabile ce determina conectarea, protocolul se încheie și începe conectarea propriu zisa a clientului la serverul respectiv. A nu se confunda noțiunea de server din cadrul acestui model cu noțiunea de calculator în sine, deseori denumit și server tocmai datorită faptului că pe el rulează o aplicație de tip server.
Dintre avantajele aplicații de tip client-server față de o aplicație clasică monoutilizator, de gestiune a bazelor de date, putem enumera:
operarea multiutilizator concurențială;
descongestionarea traficului prin rețea datorită transmiterii doar a datelor țintă;
controlul drepturilor utilizatorilor și monitorizarea activității (conectare și aplicații);
implementări unice de logică centralizată (reguli, proceduri, declanșatoare – existente doar la nivelul serverului);
gestionarea tranzacțiilor ("tranzacția = succesiune de comenzi elementare, definind unitatea logică prin care operează un pachet client“), aspect care devine capital/critic atunci când se administrează un sistem complex de date distribuite
serverul asigura integritatea, consistența și actualitatea datelor (propagări de actualizări prin mecanismele de integritate referențială);
optimizarea organizării fizice a datelor (colaborarea la un nivel cât mai jos cu sistemul de operare și cu sistemul de fișiere) și optimizarea accesului la date. (Un exemplu de colaborare la nivel fizic este posibilitatea SGBD-urilor de a face duplicări ale datelor – copiile de siguranță fiind unul dintre primele niveluri ale toleranței la defecte. Desigur ca și un LAN desktop – Novell, Windows NT – poate face mirroring, însa nuanțele diferă.)
recuperarea datelor în caz de blocare/cădere a sistemului și refacerea tranzacțiilor neterminate;
jurnalizarea acceselor, tranzacțiilor și a sesiunilor de lucru sau de administrare;
economicitatea upgrade-ului: ridicarea performantelor globale rezidă în principal în creșterea puterii calculatorului pe care rulează serverul bazei de date, privind mai puțin calculatoarele client pe care se află software-ul front-end etc
.Se cuvine sa facem o scurtă descriere a organizării client/server și să evidențiem câteva particularități interesante.
Client și server pot fi văzute și ca două procesoare distincte rulând pe mașini diferite (mai rar pe aceeași mașină), bazate eventual (dar nu obligatoriu) pe același sistem de operare.
Comunicația prin care partea "client“ a aplicației solicită servicii părții „server“ se face prin mesaje (message-passing), fiind complet transparenta utilizatorului.
Posturile de lucru pot fi uzual PC-uri, laptop-uri, stații UNIX sau Macintosh, iar serverul poate fi un mainframe, un server departamental sau chiar un PC bine dotat.
Software-ul bazelor de date implementate prin arhitectura client/server se prezintă generic astfel: SGBD-urile asigură partea de server, iar aplicațiile de exploatare a datelor se află uzual la nivelul client (sculele de editare a aplicațiilor utilizator aparțin de producătorii SGBD-urilor implementate sau pot fi din familia celor bazate pe specificații deschise: ODBC, JDBC, Embeded SQL, DCOM, OLE etc.).
Repartizarea datelor și a aplicației (logicii) între straturile "client“ și "server“ nu este preimpusă, fiecare implementare fiind susceptibilă de un optim.
Arhitectura client/server dovedește suplețe (modularitatea și scalabilitatea oferind disponibilitate crescută la reorganizări și extinderi) și deschidere (chiar se consideră ca ea a apărut din necesitatea de a asigura o deschidere și interoperabilitate superioare modelului centralizat cu mainframe).
Modelul client/server a fost si el susceptibil de perfecționări de principiu, iar una dintre cele mai interesante este impunerea de niveluri/straturi intermediare între client și server, ca răspuns la dilema legată de poziționarea programelor de aplicație (logica de operare/afacere): care dintre parți trebuie să fie mai "groase“, clientul sau serverul? Întrucât avantajele locale erau permanent necomplementare, s-a dezvoltat ideea unui strat intermediar, concretizat într-un server de aplicații interpus intre clientul subțire și serverul bazei de date (middle-tier), ambele capete fiind astfel descongestionate de partea de logică. Interesantă este și observația unor analiști care asociau tendința modernă de accentuare a clientului subțire cu revenirea la modelul mainframe + terminale "oarbe“. Oricum, cerințele actuale privind deschiderea mediilor informaționale determină diluarea graniței dintre modele, rețelele eterogene fiind văzute ca soluția cea mai viabilă de a menține echilibrul între permanentele inovații și conservarea investițiilor anterioare.
Însa cele mai deranjante dezavantaje ale arhitecturii client/server derivă din complexitatea ei (cerințe asupra personalului implicat: înțelegerea conceptuală a arhitecturii de către persoanele de decizie, precum și cunoștințe aprofundate pentru cei care implementează/dezvoltă efectiv sistemul/aplicațiile) și din standardizarea insuficientă.
Nu putem încheia capitolul despre bazele de date în arhitectura client/server fără să amintim de adaptabilitatea organică pentru Internet. Majoritatea serviciilor Internetului se desfașoară în regim client/server (banala navigare înseamnă un utilizator accesând datele dintr-un site-server prin intermediul unei aplicații client, care este browserul de Web), astfel că devine naturală implicarea SGBD-urilor în aplicații Internet (de genul e-business sau e-commerce). Să ne imaginam următorul scenariu: un furnizor de produse își organizează un catalog de produse (magazin virtual) pe care utilizatorii îl pot consulta prin navigatorul de acasă. Lucrurile se desfășoară prin pagina HTML pe care serverul de Internet o trimite clientului, la rândul ei respectiva pagina acționând ca șablon (formular/formă) de accesare a informațiilor comerciale din baza de date deservita de un server legat la site-server (cel mai frecvent baza de date conține și imagini dacă nu chiar și alte date multimedia). Iar dacă utilizatorul va comanda din produsele expuse completând un formular din pagina Web, se declanșează o altă serie de comunicații între client și server.
Schema bloc de funcționare a arhitecturii client-server
2.4. Modelul general de funcționare a unei aplicații de Home Banking bazată pe arhitectura client-server
Funcționarea unei aplicații de tip home banking HB este asigurată de două module :
(a) HB Client – se instalează la client în vederea comunicării cu banca
(b) HB Server – se instalează la bancă și asigură legătura securizată între client și datele din sistemul informatic a sucursalei.
Cu ajutorul unei aplicații home banking clientul poate să obțină (prin conectare la bancă) informații despre:
Conturile proprii (solduri, istoric tranzacții , extrase de cont)
Depozitele proprii (bonificații, extrase de depozit)
Creditele proprii (grafice de rambursare)
Cursuri valutare (BNR & Spot )
și poate efectua următoarele operațiuni:
Plăți parteneri
Plăți salariați
Plăți trezorerie
Constituiri depozite
Schimburi valutare
Programări pentru ridicare numerar
Modulul de home banking folosit de către bancă (b) ar da posibilitatea posibilitatea:
Gestionarii clientilor :
Adăugare
Ștergere
Modificare
Acordarea/retragerea dreptului de comunicație
Vizualizarea clienților conectați la un moment dat
Salvarea istoriei mesajelor serverului
Efectuării operațiunilor cerute de clienți (plăți, constituiri depozite, schimburi valutare, înregistrarea programărilor pt. ridicare numerar).
– Listări documente de plata, istorii, alte liste
– Verificarea periodica a existentei de cereri noi (netratate)
Pentru toate aceste operațiuni :
este verificată corectitudinea semnăturii și existența tuturor detaliilor necesare (sumă, explicații, …); În caz contrar cererea nu se operează.
sunt afișate toate detaliile plătii astfel încat operatorul poate verifica consistența detaliilor care nu se pot verifica prin program și poate decide dacă cererea se operează sau nu
În ceea ce privește securitatea unei astfel de aplicații:
· Datele se transferă criptat în ambele sensuri (bancă -> client , și invers)
· Clientul poate accesa programul numai pe baza de utilizator și parolă
· Clientul poate controla lista de acces proprie numai dacă este conectat și autentificat la bancă
· Restricționarea operațiunilor la client în funcție de nivelul de securitate atribuit
· Plățile și cererile către bancă sunt semnate digital
Acest gen de servicii este puțin utilizat în tara noastră, dar cu mari perspective de aplicare în următorii ani datorită creșterii numărului de tranzacții dintre bănci și clienți și a necesității de efectuare cât mai rapidă a acestora.
Schema de funcționare a unei aplicații de Home Banking pe modelul client-server
În continuare se încearcă descrierea celor mai importante activități bancare și a tipurilor de sisteme informatice existente la câteva bănci mai importante din țara noastră.
Spre exemplu Banc Post a lansat anul trecut propria soluție de Internet Banking care permite oricărui client al băncii realizarea de operațiuni bancare on-line de la distanță (din orice punct de acces Internet). Serviciul este structurat în 6 module funcționale: Administrare, Conturi, Extrase de cont, Ordine de plată în Lei și Valutare, Informații bancare. Site-ul pentru acest serviciu este asigurat și garantat de firma Verisign. Schimbul de date se efectuează securizat pe baza unui algoritm DES. Clientul primește un dispozitiv de securitate Digipass 300, cu ajutorul căruia inițiază utilizarea Internet-ului pentru a accesa informații specifice și pentru procedurile de identificare. La fiecare noua conectare se generează o alta secvență de parole.
În cazul Băncii Comerciale Române B.C.R sistemul de bancă electronică e-BCR permite, prin intermediul Internet-ului, efectuarea de plăți în lei și obținerea extraselor de cont și a unor informații de trezorerie, fără a mai fi necesară deplasarea la sediul băncii.
e-BCR este destinat clienților mici și mijlocii care realizează activitate financiar contabilă cu un număr mic de tranzacții și care nu dispun de resurse umane din domeniul informaticii pentru întreținerea unei rețele locale sau pentru realizarea unor interfețe cu propriile sisteme informatice.
Pentru aceștia conexiunea cea mai simpla la un sistem de plăti electronice este cea de tip Internet care nu cere resurse speciale pe calculatorul clientului.
Pentru a putea folosi acest sistem de plăti banca oferă clienților săi un fișier de tip plug-in sub forma unui program ce se va instala în mod automat în structura browser-ului local și care permite, în mod securizat, realizarea conexiunii cu banca.
Pentru autorizarea lucrului prin e-BCR, clientul trebuie sa realizeze următorii pași:
să aibă cont la una dintre unitățile BCR;
să completeze, la sediul unității BCR, o cerere de acces la serviciul e-BCR, semnată de persoana autorizată să efectueze operațiuni bancare și care deține semnătură în bancă;
să instaleze pe calculatorul din societate programul oferit de BCR
Banca Romana pentru Dezvoltare – Groupe Société Générale pune la dispoziția clienților un serviciu din gama produselor home banking numit „Multix” care se adresează tuturor persoanelor juridice clienti BRD – Groupe Société Générale și în special clienților care au nevoie sa efectueze un număr mare de operațiuni de plata și clienților cu mai multe conturi deschise la unități diferite. Acest serviciu poate stabili o legătură directă cu banca, bazată pe un schimb permanent de date, care permite derularea diverselor tipuri de operațiuni bancare fără a fi nevoiți să ne deplasăm din fața calculatorului nostru personal.
De obicei în aceste cazuri instalarea aplicației la client cât și instruirea acestuia cu privire la utilizarea serviciului sunt realizate în mod gratuit de către bancă.
Serviciul de home banking al B.R.D. este structurat pe patru module puse în bloc la dispoziția clientului, serviciul Multix având următoarele funcții:
1. Modulul de baza (Cash Management)
Administrarea generala a programului:
Selectarea parametrilor;
Selectarea opțiunilor disponibile;
Crearea și gestiunea limitelor de competență de utilizare a produsului la client;
Acordarea drepturilor de acces la anumite module în funcție de alegerile clientului;
Organizarea bazelor de date;
Vizualizarea și tipărirea datelor primite de la bancă (baze de date disponibile: conturi, extrase de cont, solduri, tranzacții).
Pentru limitarea volumului de date afișate sau tipărite se pot impune criterii de selecție cum ar fi: data, suma, număr cont, valuta contului, banca.
Planning – permite efectuarea unor estimări privitoare la situația ordinelor de plată. Înregistrările se pot introduce automat sau manual.
2. Modulul de plăti în lei – introducerea, aprobarea și transmiterea ordinelor de plată în lei;
3. Modulul de plăți în valută – introducerea, aprobarea și transmiterea ordinelor de plată în valută;
4. Modulul de semnătură electronică – ridicarea nivelului de securitate al operațiunilor;
Serviciul permite efectuarea plății salariilor angajaților prin emiterea unui singur ordin de plata de către acele societăți care au încheiate convenții de plata a salariilor pe card-uri cu BRD.
CAPITOLUL III
3.1. Considerații generale privind pachetul de aplicații Home Banking
Aplicația Home Banking Server este proiectată și realizată (în scopuri demonstrative, didactice) ca un complement al sistemului informatic utilizat de o bancă în mod curent, adăugând numai noi facilitați de electronic banking, deschizând practic un "ghișeu" al băncii la sediul clienților acesteia, persoane juridice.
Sistemul permite clienților introducerea tuturor Ordinelor de Plata pe care le au de făcut partenerilor de afaceri, apoi le transmite automat către banca unde sunt verificate și prelucrate, eliminând necesitatea deplasării clientului la bancă pentru a aduce fizic aceste documente.
Modelul de realizare a acestei aplicații este bazat pe arhitectura client server. Astfel aplicația server va rula pe computerul central al băncii, iar aplicațiile client vor rula pe computerele localizate la sediile firmelor client abonate la acest serviciu pus la dispoziție de către bancă. De asemenea mai există o aplicație client destinată ghișeelor de la sediile băncii din teritoriu, scopul acesteia fiind de a putea alimenta conturile clienților în momentul în care aceștia se prezintă la aceste ghișee și doresc să depună bani în conturile lor.
Aplicația server permite realizarea următoarelor atribuții:
Crearea de firme client în momentul în care acestea subscriu la serviciul de Home Banking oferit de către bancă;
Modificarea datelor despre o anumită firmă client;
Ștergerea unei firme client precum și a tuturor utilizatorilor acesteia în momentul în care aceasta decide să renunțe la serviciile băncii;
Crearea de conturi de utilizatori pentru angajații firmelor ce au subscris la acest serviciu
Ștergerea conturilor de utilizator ale angajaților firmelor client;
Blocarea conturilor de utilizator în momentul constatării unor nereguli sau la cererea firmelor client, până la soluționarea conflictelor;
Crearea de conturi bancare pentru firmele client;
Blocarea acestor conturi bancare în momentul apariției unor probleme, până la soluționarea acestora, când acestea pot fi deblocate;
Crearea unei filiale noi a băncii în momentul în care banca deschide o nouă filială într-o anumită localitate și o conectează la serviciul de Home Banking;
Modificarea datelor despre o anumită filială a băncii;
Ștergerea unei filiale precum și a tuturor utilizatorilor acesteia în momentul în care aceasta este scoasă din circuitul băncii;
Crearea de conturi de utilizatori pentru angajații filialelor băncii, lucrători la ghișeele acesteia din teritoriu;
Ștergerea conturilor de utilizator ale angajaților de la ghișeele băncii;
Blocarea conturilor de utilizator angajat la ghișeele băncii în momentul constatării unor nereguli, până la soluționarea conflictelor;
Blocarea și deblocarea accesului către server de la adrese IP considerate a nu fi de încredere;
Recepționarea ordinelor de plată de la clienți, semnate digital de către aceștia, verificarea acestora și tipărirea de rapoarte privind ordinele de plată recepționate ce vor fi transmise personalului avizat al băncii pentru onorarea plăților;
Transmiterea către clienți la solicitarea acestora a informațiilor privind starea conturilor bancare ale acestora și a altor informații utile precum cursurile valutare;
Realizarea de rapoarte privind conturile bancare deschise ale firmelor client;
Realizarea de rapoarte privind firmele client înregistrate și conturile de utilizator ale acestora, precum și conturile de utilizator ale angajaților proprii.
În continuare vom prezenta o schemă de principiu a funcționării pachetului de aplicații de Home Banking.
Pachetul de aplicații Home Banking funcționează în modul următor:
Firmele client abonate ale serviciului băncii, dotate cu computere și modem se conectează la serverul băncii pe baza unui username și a unei parole. Username-ul și parola sunt transmise securizat la server prin intermediul criptării folosind algoritmul RSA, ce folosește chei publice și chei private, prezentând un nivel de securitate maxim și folosind o cheie de criptare pe 512 biți.
Server-ul băncii primește cererea de conectare și username-ul și parola criptate cu cheia sa publică pe care o comunică fiecărui client ce dorește să se conecteze. Serverul decriptează username-ul și parola și verifică în tabela de utilizatori dacă acest cont există și dacă el este valid. De asemenea el verifică și IP calculatorului ce trimite cererea de conectare în tabela de IP-uri cu interdicție pe server. În cazul în care totul este în regulă (contul există și nu e blocat, sau nu mai există deja un utilizator deja conectat la server cu acest cont, adresa de IP nu se află în lista IP-urilor cu interdicție pe server) permite conectarea utilizatorului la server permițându-i acesta accesul la datele firmei la care este angajat.
Clientul emite cereri către server iar acesta le primește și le interpretează, furnizând informațiile necesare în funcție de cererile primite și verificând autenticitatea cererilor privind ordinele de plată primite de la clienți prin intermediul semnăturii digitale.
Clientul trimite către server cererea de deconectare în momentul în care nu mai dorește să efectueze alte tranzacții iar server-ul deblochează contul de utilizator și deconectează clientul respectiv.
În mod similar terminalele bancare aflate la ghișeul băncii se conectează la server-ul bancar pentru a alimenta conturile clienților băncii în momentul în care aceștia se prezintă fizic la ghișeele băncii pentru a face o depunere de numerar.
Pachetul de aplicații este construit de natură modulară și scalabilă permițând o eficientizare maximă a tranzacțiilor efectuate, ușurință în utilizare și totodată un grad de securitate maximă, el putând rula, dacă banca decide, în mediul Internet.
3.2. Proiectarea tabelelor utilizate de aplicația Home Banking Server
În continuare prezentăm structura tabelelor necesare pentru rularea aplicației server, menționând că acestea sunt realizate în Paradox 7, SGBD nativ mediului de programare Borland Delphi 6.0.
Tablele utilizate sunt tabele libere, neaparținând unei baze de date și neavând relații fizice între ele, relațiile necesare fiind logice, iar interogările necesare aplicației fiind realizate exclusiv prin intermediul comenzilor SQL, această tehnică având avantaje nete evidente în ceea ce privește viteza de execuție, iar flexibilitatea acestei tehnici a fost și este un subiect prezent în foarte multe lucrări de specialitate. Ea înseamnă timpi de acces și prelucrare mult diminuați, deci îmbunătățirea timpului de răspuns;
Tabela useri.db – tabela în care sunt stocate datele privitoare la utilizatorii aplicației (clienții ce beneficiază de acest serviciu al băncii).
Banca creează la cerere conturile de utilizator pentru firmele ce beneficiază de serviciul de Home Banking, cu ajutorul programului server. Datele privitoare la contul utilizatorului sunt stocate în tabela descrisă mai jos.
În momentul în care un utilizator dorește să se conecteze el trimite server-ului numele de utilizator și parola iar serverul le verifică existența în tabela useri.db și permite sau nu accesul.
Tabela useribanca.db tabela în care sunt stocate datele privitoare la utilizatorii aplicației angajați ai băncii care lucrează la ghișeele bancare.
Tabela firme.db tabela în care sunt stocate datele privitoare la firmele înregistrate ce beneficiază de acest serviciu al băncii.
Server-ul creează firmele client în momentul în care acestea solicită în scris subscrierea la serviciul bancar de Home Banking și introduce datele referitoare la acestea în tabela de mai jos.
Tabela filiale.db tabela în care sunt stocate datele privitoare la filialele băncii ce se pot conecta la server și realiza operații de alimentare a conturilor clienților ce beneficiază de serviciul de Home Banking.
Tabela conturi.db tabela în care sunt stocate datele privitoare la conturile agenților economici deschise la bancă.
Conturile sunt create în exclusivitate de către aplicația server în momentul înregistrării unei firme client și sunt alimentate cu un sold inițial. Ulterior ele pot fi alimentate numai de către ghișeele bancare în momentul depunerii unei sume în contul respectiv.
Tabela op.db este tabela în care sunt stocate datele privitoare la ordinele de plată emise de către clienții beneficiari ai acestui serviciu.
Clienții înregistrați ai băncii pot emite ordine de plată către bancă, acestea fiind semnate digital iar aplicația server le centralizează în tabela următoare.
Contul din care se face plata este debitat automat cu suma de plată și sunt întocmite rapoarte ce sunt transmise persoanelor avizate din cadrul instituției bancare pentru onorarea plăților către societățile comerciale cărora le-a fost adresată plata.
Tabela depuneri.db tabela în care sunt stocate datele privitoare la depunerile efectuate în conturile clienților beneficiari ai acestui serviciu.
Tabela cursval.db este o tabelă în care sunt stocate datele privitoare la cursurile valutare practicate de către banca la momentul respectiv. Aceste cursuri valutare sunt oferite cu titlu informativ clienților băncii ele putând fi solicitate de către aceștia din aplicația client.
Tabela ip.db este o tabelă în care serverul reține adrese IP ce sunt considerate a nu fi de încredere, cărora le blochează accesul către server. Orice conexiune primită de la aceste adrese va fi deci refuzată de către server.
În ceea ce privește aplicația client aceasta nu stochează pe calculatorul gazdă nici un fel de informații, rolul deținerii și administrării informației revenind în exclusivitate server-ului, din motive de securitate și pentru a respecta standardele modelului de proiectare a aplicațiilor pe arhitectura client-server. Totuși, pentru afișarea unor interogări pe care clientul le transmite server-ului sunt necesare două tabele temporare în care sunt salvate informațiile primite de la server, în scopul întocmirii de rapoarte de către aplicația client, tabele ce sunt imediat golite după întocmirea rapoartelor necesare.
3.3. Proiectarea procedurilor
Pachetul de aplicații Home Banking a fost realizat sub mediul de programare Borland Delphi 6.0, din motive ce țin de ușurința, flexibilitatea și adaptabilitatea acestui mediu puternic de programare ce pune la dispoziția programatorului o serie de instrumente variate pentru lucrul în rețea și cu bazele de date, dar și o serie de instrumente necesare realizării unei interfețe grafice prietenoase.
În continuare voi prezenta mai multe porțiuni considerate mai importante din codul sursă al aplicației, încercând să accentuez comunicarea între aplicația server și cea client, întrucât aceasta prezintă cel mai mare interes în cazul acestui pachet software. Prezentarea codului sursă se va face printr-un paralelism între programul server și cel client, pentru a înțelege mai bine interfața de comunicare între cele două aplicații.
Aplicația folosește o serie de componente pentru modelul client server, și anume componenta Indy TCP server și Indy TCP client, componente bazate pe protocolul de comunicare TCP/IP. De asemenea trebuie menționat că aplicația server va deschide câte un fir de execuție separat pentru fiecare client, pentru a putea face față mai multor cereri în același timp, fapt ce se dovedește a fi mare consumator de resurse, de aceea recomandându-se folosirea unui sistem cât mai performant pentru găzduirea aplicației server.
Vom începe cu procedura prin care clientul se conectează la server pentru identificare folosind numele de utilizator și parola:
Partea de cod sursă pe care o execută aplicația client este următoarea:
client.Connect; // Realizez conexiunea cu componenta server
try
client.WriteLn('doresc cheia serverului'); // Trimit cererea catre server pt primirea cheii RSA
serverkey:=client.ReadLn; // Aici primesc cheia publica a serverului cu care criptez mesajele
// Aici criptez numele si parola pentru a fi transmise securizat server-ului
keyrsa.RSA.PublicKey:=serverkey; // Incarc in componenta de RSA cheia publica a serverului
keyrsa.RSA.EncryptString(form1.Edit1.Text,numecriptat);
keyrsa.RSA.EncryptString(form1.Edit2.Text,parolacriptata);
client.WriteLn('vreau sa ma conectez'); // Trimite server-ului cererea de conectare
client.WriteLn(numecriptat); // Trimite server-ului numele
client.WriteLn(parolacriptata); // Trimite server-ului parola
client.WriteLn(form1.curentip); // Trimit la server IP local al clientului
user:=form1.Edit1.Text;
mesaj:=client.readln(); // Primesc un raspuns de la server
finally
end; // Se analizeaza mesajul primit de la server
if mesaj='ok' then begin // Daca serverul isi da acordul de conectare
form2.Label1.Caption:='Data:'+DateToStr(Date);
form2.Label4.Caption:='Data:'+timeToStr(time);
form2.Label2.Caption:=client.ReadLn();
cdfiscal:=client.ReadLn(); // Primeste codul fiscal al firmei
denfirma:=client.ReadLn(); // Primeste denumirea firmei
form2.Label6.Caption:='Firma: '+denfirma;
form2.Label3.Caption:='Ati fost autentificat de cãtre server !';
client.Disconnect; // Deconectez clientul
end else
if mesaj='esti blocat' then begin // Daca contul a fost blocat de catre server
form2.Label1.Caption:='Data:'+DateToStr(Date); // si serverul respinge conectarea
form2.Label4.Caption:='Data:'+timeToStr(time);
form2.Label2.Caption:='Neautorizat';
form2.Label3.Caption:='Ati fost blocat de cãtre server !';
client.Disconnect;
end else
if mesaj='cont deja in uz' then begin // Daca respectivul cont e deja in uz
form2.Label1.Caption:='Data:'+DateToStr(Date);
form2.Label4.Caption:='Data:'+timeToStr(time);
form2.Label2.Caption:='Neautorizat';
form2.Label3.Caption:='Acest utilizator este deja conectat !';
client.Disconnect;
end else begin // Daca numele si/sau parola nu sunt corecte
form2.Label1.Caption:='Data:'+DateToStr(Date);
form2.Label4.Caption:='Data:'+timeToStr(time);
form2.Label2.Caption:='Neautorizat';
form2.Label3.Caption:='Nu aþi fost autentificat de cãtre server !';
client.Disconnect;
end;
Partea de cod sursă pe care o execută aplicația server pentru a răspunde cererii clientului este următoarea:
procedure TForm1.ServerExecute(AThread: TIdPeerThread);
var suma,username,password,nume,parola,blocaj,cerere,codfiscal,nrcont,sold,nrop:string;
numeemitent,platitor,descriere,bancabeneficiar,contbeneficiar,beneficiar:string;
k,summa : integer;
fis:textfile;
operator,filiala,deponent,mentiuni,cont,status,clientip:string;
numedecriptat,paroladecriptat,data1,data2:string;
begin
with AThread.Connection do // Aici serverul deschide un fir de executie
begin
// Aici primeste tipul de cerere de la client si in functie de asta face ce trebuie
try
cerere:=readln;
finally
end;
// Aici trimit cheia RSA publica a serverului catre clientii ce vor sa se conecteze
if cerere='doresc cheia serverului' then begin
form1.ListBox1.Items.Add('Trimis cheie publica > '+rsapublic);
writeln(rsapublic);
end;
// Aici trateaza cererea de conectare a unui client al bancii
if cerere='vreau sa ma conectez' then begin
try
nume:=readln;
parola:=readln;
clientip:=readln;
finally
end;
// Incarc in componenta de RSA cheia publica si cea privata a serverului
form1.RSA.PrivateKey:=rsaprivat;
form1.RSA.PublicKey:=rsapublic;
// Decriptez numele si parola primite
form1.RSA.DecryptString(nume,numedecriptat);
form1.RSA.DecryptString(parola,paroladecriptat);
nume:=numedecriptat;
parola:=paroladecriptat;
form1.ListBox1.Items.Add('Data si ora conectarii > '+datetostr(date)+' '+timetostr(time));
form1.ListBox1.Items.Add('Utilizator > '+nume);
form1.ListBox1.Items.Add('Parola > '+parola);
form1.ListBox1.Items.Add('Adresa IP client > '+clientip);
// Vreau sa verific daca IP este in lista celor neacceptate (e banned)
ip.Active:=true;
if ip.Locate('Ip',clientip,[loCaseinsensitive]) then begin
try
writeln('esti blocat');
finally
end;
form1.ListBox1.Items.Add('Respins – Motiv -> IP refuzat');
end else begin
table1.Active:=true;
if table1.Locate('username;password;blocat', VarArrayOf([nume,parola,1]),[loCaseinsensitive]) then begin
form1.ListBox1.Items.Add('Autentificat client');
// Blocam contul ptr a nu se putea conecta 2 util cu acelasi username si password
form1.Table1.Edit;
form1.Table1.FieldValues['Blocat']:=0;
form1.Table1.FieldValues['Ip']:=clientip;
// 1 cont valid
// -1 cont blocat
// 0 contul este in uz (cineva e conectat cu el)
form1.Table1.Post;
try
writeln('ok');
indx1:=form1.ListBox2.Items.Count+1;
writeln(Form1.Table1.Fields[0].AsString);
writeln(Form1.Table1.Fields[6].AsString);
form1.Table2.Active:=true;
if table2.Locate('Codfisc',Form1.Table1.Fields[6].AsString,[loCaseinsensitive]) then
writeln(Form1.Table2.Fields[1].AsString);
form1.Table2.Active:=false;
finally
end;
end else
if table1.Locate('username;password;blocat', VarArrayOf([nume,parola,-1]) , [loCaseinsensitive]) then begin
form1.ListBox1.Items.Add('Respins – Motiv -> Cont blocat');
try
writeln('esti blocat');
writeln(Form1.Table1.Fields[0].AsString);
finally
end;
end else
if table1.Locate('username;password;blocat', VarArrayOf([nume,parola,0]),[loCaseinsensitive]) then begin
form1.ListBox1.Items.Add('Respins – Motiv -> Cont deja in uz');
try
writeln('cont deja in uz');
writeln(Form1.Table1.Fields[0].AsString);
finally
end;
end else begin
form1.ListBox1.Items.Add('Respins – Motiv -> Cont inexistent');
try
writeln('nu e bine');
finally
end;
end;
table1.Active:=false;
end;
ip.Active:=false;
end;
După cum se poate observa după studiul codului sursă prezentat mai sus între client și server are loc următorul protocol de „discuție”: clientul cere prima dată cheia RSA publică a server-ului pentru a putea transmite acestuia username-ul și parola criptate cu ajutorul algoritmului de criptare RSA, implementat cu ajutorul unei componente specifice. Server-ul răspunde clientului transmițându-i cheia sa RSA publică. Clientul trimite mesajul „vreau sa ma conectez” către server, ceea ce pentru server are înțelesul de cerere de conectare a unui client, apoi criptează username-ul și parola și o trimite la server. Acesta primește șirurile de caractere criptate și le decriptează cu algoritmul RSA, folosind cheia sa privată pentru decriptare obținând username-ul și parola în clar, apoi caută în tabela useri.db ce conține utilizatorii înregistrați dacă există un utilizator cu numele și parola primite de la client. De asemenea el verifică dacă acel utilizator este sau nu blocat de către administratorul serverului sau dacă nu mai exisă deja cineva deja conectat cu aceste date, fapt ce înseamnă că cineva încearcă o intruziune folosind un cont posibil furat. În funcție de răspunsul găsit după interogarea tabelei cu utilizatori server-ul transmite clientului un răspuns ce constă în faptul că cererea este acceptată sau respinsă și motivele respingerii. În funcție de răspunsul primit aplicația client știe dacă este permisă sau nu conectarea respectivului utilizator și permite sau nu accesul către nivelul următor constând în forma principală a aplicației ce conține meniurile.
În continuare vom mai prezenta o parte a codului sursă pe care o consider foarte importantă și anume modul cum este transmis un ordin de plată către aplicația server, după ce în prealabil a fost semnat digital de către client.
Partea de cod sursă la nivelul aplicației client este următoarea:
procedure Tordinplata.Button1Click(Sender: TObject);
var raspuns:string; // raspunsuri primite de la server
execut:boolean;
begin
execut:=true;
// Aici incepe validarea datelor la nivelul clientului
if (ordinplata.Edit1.Text='') or (strtoint(ordinplata.Edit1.Text)<=0) then begin
showmessage('Nr. ordin de plata gresit!');
ordinplata.Edit1.SetFocus;
end else
if (ordinplata.Edit2.Text='') or (strtoint(ordinplata.Edit2.Text)<=0) then begin
showmessage('Contul indicat este introdus gresit gresit!');
ordinplata.Edit2.SetFocus;
end else
if ordinplata.Edit3.Text='' then begin
showmessage('Va rog completati explicatia!');
ordinplata.Edit3.SetFocus;
end else
if (ordinplata.Edit4.Text='') or (strtoint(ordinplata.Edit4.Text)<=0) then begin
showmessage('Suma de plata este gresita!');
ordinplata.Edit4.SetFocus;
end else
if ordinplata.Edit5.Text='' then begin
showmessage('Va rog completati beneficiarul!');
ordinplata.Edit5.SetFocus;
end else
if (ordinplata.Edit6.Text='') or (strtoint(ordinplata.Edit6.Text)<=0) then begin
showmessage('Va rog completati contul beneficiarului!');
ordinplata.Edit6.SetFocus;
end else
if ordinplata.Edit7.Text='' then begin
showmessage('Completati va rog banca beneficiarului!');
ordinplata.Edit7.SetFocus;
end else begin // Datele au fost validate la nivel de client
// Incepem validarea datelor cu serverul
// Validarea nr-lui ordinului de plata
form3.Client.Connect;
form3.client.WriteLn('valideaza nr ordin de plata');
form3.client.WriteLn(ordinplata.Edit1.Text);// Trimit la server nr OP-ului
form3.client.WriteLn(form1.cdfiscal);// Trimit la server codul fiscal al firmei emitente
raspuns:=form3.Client.ReadLn(); //Primesc raspuns de la server si tratez in consecinta
form3.Client.Disconnect;
if raspuns<>'ok' then begin // Daca nr de ordin de plata exista deja
execut:=false;
ShowMessage('Acest nr de OP exista deja! Alegeti altul!');
ordinplata.Edit1.SetFocus;
end;
// Aici verific daca exista contul respectiv sau daca e blocat tot la nivelul server
// si daca are suficienti bani disponibili ptr a efectua plata
form3.Client.Connect;
form3.client.WriteLn('verifica contul');
form3.client.WriteLn(form1.cdfiscal);// Trimit la server codul fiscal al firmei emitente
form3.client.WriteLn(ordinplata.Edit2.Text); // Trimit nr de cont din care se face plata
form3.client.WriteLn(ordinplata.Edit4.Text); // Trimit suma de plata
raspuns:=form3.Client.ReadLn(); //Primesc raspuns de la server si tratez in consecinta
form3.Client.Disconnect;
if raspuns='inexistent' then begin //Daca contul nu exista
execut:=false;
ShowMessage('Acest cont nu exista! Verificati!');
ordinplata.Edit2.SetFocus;
end else
if raspuns='cont blocat' then begin //Daca contul exista dar e blocat
execut:=false;
ShowMessage('Acest cont este blocat de catre banca!');
ordinplata.Edit2.SetFocus;
end else
if raspuns='cash not enough' then begin //Daca contul exista dar nu are bani destui
execut:=false;
ShowMessage('Acest cont nu are suficient disponibil!');
ordinplata.Edit4.SetFocus;
end;
if execut=true then begin // Daca totul e OK trimit OP-ul la server care il accepta
// daca semnatura digitala se verifica
form3.Client.Connect;
// semnez digital cererea de inregistrare a OP-ului
semneazadigital('inregistreaza op');
form3.client.WriteLn('inregistreaza op'); // trimit cerere de inregistrare a OP-ului
form3.client.WriteLn(ordinplata.textsemnatdigital); // Trimit la server semnatura obtinuta
form3.client.WriteLn(form1.user); // Trimit username-ul ptr verificarea semnaturii la server
form3.client.WriteLn(ordinplata.Edit1.Text); //Trimit nr OP
form3.client.WriteLn(ordinplata.Label13.Caption); //Trimit platitorul
form3.client.WriteLn(ordinplata.Label14.Caption); //Trimit cod fiscal platitor
form3.client.WriteLn(ordinplata.Edit2.Text); //Trimit contul platitorului
form3.client.WriteLn(ordinplata.Edit3.Text); //Trimit descrierea platii
form3.client.WriteLn(ordinplata.Edit4.Text); //Trimit suma de plata
form3.client.WriteLn(ordinplata.Edit5.Text); //Trimit numele beneficiarului
form3.client.WriteLn(ordinplata.Edit6.Text); //Trimit cont beneficiar
form3.client.WriteLn(ordinplata.Edit7.Text); //Trimit numele bancii beneficiarului
form3.client.WriteLn(form2.Label2.Caption); // Trimit numele utilizatorului care a emis OP
raspuns:=form3.Client.ReadLn();
form3.Client.Disconnect; // Deconectam Clientul
if raspuns='Semnatura este verificata' then begin
showmessage('Ordinul de plata a fost transmis bancii!');
// Pregatim raportul cu ordinul de plata emis ptr listare
raportop.QRLabel2.Caption:= ordinplata.Edit1.Text; //Trimit nr OP
raportop.QRLabel3.Caption:='PLATITOR: '+ordinplata.Label13.Caption; //Trimit platitorul
raportop.QRLabel4.Caption:='COD FISCAL: '+ordinplata.Label14.Caption; //Trimit cod fiscal platitor
raportop.QRLabel13.Caption:='DIN CONT: '+ordinplata.Edit2.Text; //Trimit contul platitorului
raportop.QRLabel6.Caption:='REPREZENTIND PLATI: '+ordinplata.Edit3.Text; //Trimit descrierea platii
raportop.QRLabel14.Caption:='PLATITI: '+ordinplata.Edit4.Text; //Trimit suma de plata
raportop.QRLabel7.Caption:='CATRE BENEFICIAR: '+ordinplata.Edit5.Text; //Trimit numele beneficiarului
raportop.QRLabel8.Caption:='IN CONT: '+ordinplata.Edit6.Text; //Trimit cont beneficiar
raportop.QRLabel9.Caption:='LA BANCA: '+ordinplata.Edit7.Text; //Trimit numele bancii beneficiarului
raportop.QRLabel10.Caption:='DATA EMITERII: '+datetostr(date); // Data emiterii OP
raportop.QRLabel12.Caption:='ORA EMITERII: '+timetostr(time); // Ora emiterii OP
raportop.QRLabel11.Caption:='ORDIN DE PLATA EMIS DE: '+form2.Label2.Caption; // Numele utilizatorului care emite OP-ul
raportop.QuickRep1.Preview; // Deschid raportul ptr preview
ordinplata.Close;
end else
showmessage('Banca refuza ordinul de plata. Semnatura nu corespunde.');
end;
end;
end;
După cum se poate observa la o analiză mai atentă a codului sursă prezentat mai sus, pentru ca ordinul de plată să se transmită în siguranță la server-ul bancar se fac o serie de validări, atât la nivelul aplicației client cât și la nivelul aplicației server. Astfel, într-o prima etapă se face verificarea la nivel de client a datelor introduse de către emitentul ordinului de plată. Această validare constă în principiu în verificarea faptului că toate câmpurile formularului au fost completate cu datele necesare emiterii ordinului de plată. După ce s-a realizat această validare se trece la prima validare a datelor cu server-ul. Aceasta se realizează astfel. Clientul trimite la server o cerere de validare a numărului ordinului de plată pentru a se vedea dacă mai există sau nu un număr identic cu cel introdus de utilizator, pentru firma client respectivă. Server-ul primește informația de la client, face verificarea în tabela cu ordinele de plată, op.db după care comunică rezultatul clientului care acționează în consecință, adică dacă numărul de ordin există deja va cere utilizatorului să introducă altul. După ce a fost validat numărul ordinului de plată se trece la validarea contului bancar folosit pentru plată și a disponibilului de numerar din respectivul cont. Astfel, aplicația client transmite la server numărul contului din care dorește să efectueze plata, precum și suma dorită. Aplicația server primește informațiile constând în codul fiscal al firmei client emitente, numărul contului și suma de plată și verifică contul respectiv (în tabela conturi.db), dacă există, dacă este blocat și dacă are suficient numerar și în funcție de rezultatul obținut răspunde clientului. Acesta primește rezultatul căutării de la aplicația server și o interpretează. Dacă respectivul cont nu există, sau este blocat, sau dacă nu dispune de suficient numerar pentru desfășurarea tranzacției va afișa utilizatorului un mesaj corespunzător îndrumându-l asupra datelor ce trebuiesc modificate în vederea realizării unei tranzacții. Dacă răspunsul primit de la server este afirmativ și operația se poate desfășura, atunci aplicația client semnează digital (cu ajutorul cheii RSA private a utilizatorului) ordinul de plată și îl transmite aplicației server. Acesta primește numele utilizatorului (username-ul) precum și semnătura digitală generată de aplicația client. El procedează în continuare la căutarea utilizatorului în tabela de utilizatori useri.db a utilizatorului transmis de către client și extrage de aici cheia RSA publică a acestuia pentru verificarea semnăturii digitale primite. Cu ajutorul componentei RSA implementate, verifică autenticitatea semnăturii primite. Dacă semnătura e autentică el va proceda la înregistrarea noului ordin de plată pentru firma client căruia îi aparține utilizatorul emitent și va proceda totodată la debitarea contului respectiv (din care se efectuează plata). Dacă semnătura nu este autentică server-ul nu va accepta ordinul de plată și va trimite către aplicația client un mesaj corespunzător de refuzare a semnăturii digitale.
Partea de cod la nivelul server-ului ce corespunde cererilor emise de client este:
// Aici rezolv cererea ptr validarea unui nr de ordin de plata
if cerere='valideaza nr ordin de plata' then begin
try
nrop:=readln; //Primeste NR OP-ului de verificat si
codfiscal:=readln; //codul fiscal al firmei emitente
finally
end;
form1.ordplata.Active:=true;
if form1.ordplata.Locate('Nr;Codfisc', VarArrayOf([nrop,codfiscal]),[loCaseinsensitive]) then writeln('not ok')
else writeln('ok');
form1.ordplata.Active:=false;
end;
// Aici rezolv cererea ptr validarea unui cont pentru o anumita firma
// si daca are disponibila o anumita suma
if cerere='verifica contul' then begin
try
codfiscal:=readln; //codul fiscal al firmei emitente
nrcont:=readln; //Primeste contul de verificat
suma:=readln; // Primeste suma ptr debitarea contului
finally
end;
form1.Table3.Active:=true;// Activez tabela cu conturi
if form1.Table3.Locate('Nrcont;Codfirma;Blocat', VarArrayOf([nrcont,codfiscal,-1]),[loCaseinsensitive]) then writeln('cont blocat') else
if form1.Table3.Locate('Nrcont;Codfirma;Blocat', VarArrayOf([nrcont,codfiscal,1]),[loCaseinsensitive]) then begin
summa:=strtoint(suma);
summa:=summa-form1.Table3.Fields[2].AsInteger;
if summa<=0 then
writeln('ok') // Dam acordul ptr plata
else writeln('cash not enough'); // nu ajung banii din cont
end else writeln('inexistent');
form1.Table3.Active:=false;// Dezactivez tabela cu conturi
end;
// Aici inregistrez un ordin de plata emis de un client
if cerere='inregistreaza op' then begin
try
semnaturaclient:=readln; // semnatura digitala a clientului
form1.ListBox1.Items.Add('Semnatura digitala a clientului:');
form1.ListBox1.Items.Add(semnaturaclient);
username:=readln; // Primeste numele de utilizator
nrop:=readln; // nr. OP
form1.ListBox1.Items.Add('Nr OP > '+nrop);
platitor:=readln; //Primeste platitorul
codfiscal:=readln; // Primeste codul fiscal al platitorului
nrcont:=readln; // contul platitorului
descriere:=readln; //descrierea platii
suma:=readln; //suma de plata
beneficiar:=readln; // beneficiarul platii;
contbeneficiar:=readln; // contul beneficiarului
bancabeneficiar:=readln; // Banca beneficiarului
numeemitent:=readln; // Utilizatorul care a emis OP-ul
finally
end;
// Aici extrag cheia RSA publica a clientului ptr verificarea semnaturii digitale
form1.Table1.Active:=true;
form1.Table1.Locate('Username',username,[loCaseinsensitive]);
form1.cheieclient:=form1.Table1.Fields[8].AsString;
form1.Table1.Active:=false;
// Verific semnatura digitala primita
form1.RSA.PublicKey:=form1.cheieclient;
form1.RSA.Signature:=semnaturaclient;
verificasemnatura(cerere); // Verfica textul clar cu semnatura primita
if form1.verificatsemnatura then begin
try
writeln('Semnatura este verificata');
finally
end;
// debitam contul cu suma platita
form1.Table3.Active:=true;
form1.Table3.Locate('Nrcont;Codfirma', VarArrayOf([nrcont,codfiscal]),[loCaseinsensitive]);
form1.Table3.Edit;
summa:=strtoint(suma);
summa:=summa-form1.Table3.Fields[2].AsInteger;
form1.Table3.FieldValues['Sold']:=-summa;
form1.Table3.Post;
form1.Table3.Active:=false;
form1.ListBox1.Items.Add('Semnatura este verificata OK');
// Adaugam ordinul de plata la tabela op.db
form1.ordplata.Open;
form1.ordplata.AppendRecord([strtoint(nrop),platitor,codfiscal,nrcont,bancabeneficiar,descriere,suma,beneficiar,contbeneficiar,date,timetostr(time),numeemitent]);
form1.ordplata.Close;
form1.ListBox1.Items.Add('OP-ul a fost inregistrat cu succes!');
end else begin
form1.ListBox1.Items.Add('Semnatura nu corespunde > OP refuzat');
try
writeln('Semnatura nu corespunde');
finally
end;
end;
end;
Următoarele proceduri sunt folosite pentru semnarea digitală și verificarea efectivă a amprentei semnăturii digitale folosind componenta Delphi de RSA.
procedure semneazadigital(text: string);
var
Digest: array[1..20] of Byte;
i: integer;
begin
FillChar(Digest, Sizeof(Digest), #0);
for i := 1 to Length(Text) do
begin
Digest[i mod Sizeof(Digest)] := Digest[i mod Sizeof(Digest)] xor
Ord(Text[i]);
end;
// crearea semnaturii digitale
ordinplata.RSA1.Sign(Digest, Sizeof(Digest));
// Incarca semnatura obtinuta intr-o variabila privata a formei
ordinplata.textsemnatdigital := ordinplata.RSA1.Signature;
end;
Procedura prezentată mai sus realizează calcularea semnăturii digitale a textului furnizat ca parametru și o depune într-o variabilă privată a formei.
Procedura de mai jos realizează verificarea semnăturii digitale pentru textul furnizat ca parametru și returnează o valoare logică (adevărat sau fals) într-o variabilă privată a formei.
Ambele proceduri folosesc atât pentru calcularea semnăturii cât și pentru verificarea acesteia o funcție de dispersie criptografică moderată (pentru mărirea vitezei de calcul a semnăturii), întrucât aplicația este realizată în scopuri didactice, pentru aplicarea într-un caz real recomandând o funcție de dispersie criptografică mai puternică, după un algoritm hash.
// Procedura de verificare a semnaturii digitale
procedure verificasemnatura(text: string);
var
Digest: Array[1..20] of Byte;
i: integer;
begin
FillChar(Digest, Sizeof(Digest), #0);
for i := 1 to Length(Text) do
begin
Digest[i mod Sizeof(Digest)] := Digest[i mod Sizeof(Digest)] xor
Ord(Text[i]);
end;
// verificarea semnaturii
form1.Verificatsemnatura := form1.RSA.Verify(Digest, Sizeof(Digest));
end;
Trebuie menționat că aceste două proceduri funcționează numai dacă în prealabil au fost încărcate perechile de chei RSA corespunzătoare cu ajutorul următoarelor instrucțiuni:
form1.RSA.SetPublicKey(cheieRSApublica);
form1.RSA.SetPrivateKey(cheieRSAprivata);
Pentru mai multe detalii privind implementarea algoritmilor de criptare și semnătură digitală în mediile de programare Borland Delphi și C Builder, se recomandă vizitarea paginii www.crypto-central.com .
Utilizarea aplicației Home Banking Server
Aplicația Home Banking Server este proiectată folosind protocolul TCP/IP putând fi folosită atât în cadrul unei rețele locale (Intranet) cât și în cadrul rețelei Internet. Aplicația este destinată băncilor pentru asigurarea serviciilor de Bancă la domiciliu.
Aplicația server rulează numai pe computerul central al băncii și este operată de către personalul autorizat de către bancă, datele fiind strict confidențiale.
Formularul principal al aplicației server conține meniul principal din care se pot accesa funcțiile principale ale aplicației, așa cum se poate vedea în imaginea următoare.
După cum se poate observa în imaginea de mai sus în partea din stânga este o listă cu mesajele primite de la clienți și mesajele trimise către clienți precum și modul de rezolvare a cererilor primite de la aceștia, listă folositoare pentru monitorizarea modului de funcționare a aplicației.
În lista din mijloc se vor afișa toți clienții conectați în acel moment la server precum și adresa IP a acestora.
În ultima listă se vor putea observa angajații de la ghișeele băncii ce sunt conectați la aplicația server.
După cum se poate observa server-ul afișază adresa IP și numele calculatorului pe care rulează precum și data și ora la care a fost lansat în execuție.
Meniul aplicației server este următorul:
Meniul Firme client permite gestionarea firmelor client și lansează un submeniu cu următoarele opțiuni: Înregistrare firma, Ștergere firmă, Modificare firmă.
Opțiunea Înregistrare firmă permite înregistrarea unei noi firme client ce dorește să beneficieze de serviciul de Home Banking, lansând în execuție formularul alăturat.
Se completează căsuțele de text respective cu datele firmei client, și se apasă butonul Înregistrare pentru a fi înregistrată noua firmă, făcându-se verificarea integrității datelor introduse.
Opțiunea Ștergere firmă lansează în execuție un formular ce permite ștergerea unei firme client în momentul în care aceasta dorește să renunțe la serviciile de Home Banking oferite de către bancă. De asemenea sunt șterse în acel moment și toate conturile acestei firme precum și toți utilizatorii acesteia. Formularul se poate vedea în imaginea de mai jos:
Administratorul server-ului selectează din combo box una din firmele client existente, iar în textbox-urile de mai jos apar datele aferente firmei respective. Ștergerea efectivă se realizează prin acționarea butonului Ștergere firmă.
Opțiunea Modificare firmă permite modificarea datelor de înregistrare a unei firme client.
Administratorul server-ului selectează din combo box una din firmele client existente, iar în textbox-urile de mai jos apar datele aferente firmei respective ce pot fi modificate. Apăsând butonul Salvează modificările se realizează modificarea datelor referitoare la firma selectată.
Următorul meniu, Filiale permite gestionarea filialelor băncii și este similar cu meniul descris anterior permițând adăugarea ștergerea și modificarea datelor referitoare la filialele băncii.
Meniul Utilizatori este destinat gestiunii utilizatorilor aplicației, adică creării, ștergerii sau blocării utilizatorilor ce folosesc aplicația client și care doresc să se conecteze la server. Acest meniu lansează un submeniu cu următoarele opțiuni: Utilizator nou, Blocare utilizator, Ștergere utilizator.
Opțiunea Utilizator nou lansează un formular cu ajutorul căruia administratorul aplicației server poate crea utilizatori noi pentru firmele ce au subscris la serviciul de Home Banking.
Se introduc datele referitoare la noul utilizator și se acționează butonul Creare. Aplicația face verificarea datelor introduse astfel încât să nu existe doi utilizatori cu același username și verifică dacă parola introdusă are minim șase caractere, dacă aceasta conține
username-ul sau inversul acestuia și solicită să conțină cel puțin un caracter non alfanumeric (de exemplu @_#¤%&) pentru mărirea securității. Ulterior fiecare utilizator poate să-și modifice parola din aplicația client.
Opțiunea Blocare utilizator servește la blocarea contului unui utilizator astfel încât acesta să nu poată să folosească temporar serviciul de Home Banking. Blocarea unui cont de utilizator nu se poate realiza decât de către aplicația server.
Administratorul acționează butoanele de navigare pentru a selecta utilizatorul dorit și acționează butonul Blochează blocând astfel utilizatorul respectiv. Tot cu ajutorul acestui formular se poate realiza deblocarea unui cont blocat anterior, caz în care butonul va fi etichetat Deblochează. În partea de jos se poate observa starea contului utilizator și anume : Neconectat la server, Blocat de server sau Conectat la server.
Opțiunea Ștergere utilizator realizează ștergerea unui utilizator din baza de date a serverului fapt ce nu va mai permite acelui utilizator accesul la serviciile server-ului.
Administratorul acționează butoanele de navigare pentru a selecta utilizatorul dorit și acționează butonul ștergând astfel utilizatorul respectiv.
Urmează meniul Angajați, ce conține un submeniu format din trei opțiuni: Angajat nou, Blocare angajat și Ștergere angajat, ce permit gestionarea conturilor angajaților proprii ai băncii, lucrători la ghișeele bancare. Modul de utilizare este similar cu cel al opțiunilor descrise mai sus în cadrul meniului Utilizatori.
Meniul Conturi este destinat gestionării conturilor existente în sistemul băncii. Acest meniu cuprinde un submeniu cu următoarele opțiuni: Creare cont, Blocare cont și Lista conturi.
Opțiunea Creare cont este destinată creării unui cont bancar nou pentru o firmă abonată la serviciul de Home Banking.
Astfel administratorul server-ului poate crea noi conturi bancare prin completarea formularului prezentat în imaginea de mai jos. Crearea efectivă a contului se face acționând butonul Creare cont. Aplicația server face validarea datelor verificând dacă toate câmpurile sunt corect completate și dacă nu mai există încă un cont care să aibă alocat deja același număr, caz în care va avertiza administratorul să aleagă alt număr. Contul poate fi încărcat cu o sumă inițială și devine operațional pentru client imediat.
Opțiunea Blocare cont permite administratorului blocarea unui cont bancar în cazul în care s-au ivit conflicte cu acest cont sau la cererea autorităților legale. Tot cu ajutorul acestei opțiuni poate fi făcută și deblocarea contului după soluționarea conflictelor ce au condus la blocarea sa. Formularul folosit poate fi observat în imaginea de mai jos.
Opțiunea Lista conturi permite vizualizarea în cadrul unui control de tip grid a tuturor conturilor deschise la bancă pentru firmele client abonate, precum și tipărirea unui raport cu aceste conturi, raport ce poate fi observat ca ANEXA 1.
Meniul Ordine de plată realizează o serie de interogări asupra tabelei în care sunt înregistrate ordinele de plată primite de la clienți în vederea vizualizării acestora și pentru tipărirea unui raport ce va fi transmis mai departe personalului băncii pentru onorarea acestora.
După cum se observă se pot vizualiza și tipări toate ordinele de plată primite în ziua curentă, într-un anumit interval de timp sau de la o anumită firmă client. Raportul obținut poate fi observat ca ANEXA 2.
Meniul Curs valutar permite administratorului să seteze valorile cursului de schimb valutar practicat de către bancă la valutele convertibile pentru a putea informa clienții asupra cursului valutar practicat de către bancă. Formularul folosit este prezentat mai jos.
Meniul Blocaje IP este destinat filtrării adreselor de IP ale clienților în vederea refuzării cererii de conectare din partea unor clienți al căror IP nu este considerat de încredere. Administratorul adaugă sau elimină cu ajutorul acestui formular adrese de IP pe care aplicația server le va respinge la primirea cererii de conectare.
Astfel la o cerere de conectare aplicația server verifică dacă IP-ul calculatorului client se află în lista de IP-uri blocate și în caz că o găsește refuză conexiunea.
Următorul meniu, Lista mesajelor
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Aplicatie Informatica Privind Realizarea Unui Ghiseu Bancar Virtual (ID: 149045)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.