Servicii de implementare a soluțiilor informatice de operaţiuni bancare și de gestionare a resurselor corporative (licențe, servicii de implementare și servicii de garanție) - REPETAT

Dear economic operator, if a tenderer submits bids for both Lot I and Lot II, they may choose the format in which the Tender Security is provided. Specifically, the Economic Operator has the right to either: • submit a single consolidated Tender Security covering both lots, in an amount at least to 1% of the total combined bid value (excluding VAT), or • submit separate Tender Securities for each lot, each amounting at least to 1% of the respective lot’s bid value (excluding VAT). Both options are acceptable and will be considered compliant with the tender requirements. At the same time, Economic Operators should consider that, if they submit bids for both lots, they are required to upload in the MTender system the full set of mandatory documents (at least the six required documents of the bid) separately for each lot.

According to the requirement set out in „The Specifications”, CL.15 “The licenses related to the proposed solution must be perpetual. The Tenderer undertakes to provide all licensing conditions and usage restrictions applicable under various circumstances.” In the understanding of the Contracting Authority, perpetual licenses are those that grant an indefinite, non-expiring right of use. After their acquisition, the user is not required to renew the license itself, but only to pay annual maintenance fees in accordance with the terms specified in the TCO (Annex 4 to „The Specifications”). Therefore, an offer based on licenses with a fixed price limited to a period of 3 years would not be considered compliant with the requirement for perpetual licensing. Also, in the context of licensing aspects, it is to be mentioned that regarding complementary licenses, load balancers are excluded from the scope of these licenses.

The specific localization requirements will be further identified by the Contracting Authority together with the Bidder (Vendor) during the analysis and design phase, based on national regulatory and operational needs. NBM accounting is IFRS and Law 287/2017 based. As examples of documents may be: Payment Order format, Accounting Note format, Invoice format (main identifications of supporting data), the format of Accounting registers, Account statement, statistical reports (including coding of operations), tax reports (VAT report – type of operations). All data (nomenclator and formats) will be provided by NBM during the analysis and design phase.

Securities accepted as collateral are securities that the NBM has approved as eligible to be used as collateral in its operations. Securities pledged in favor of NBM are securities that have been formally pledged (legally encumbered) to the NBM as security for a specific credit or liquidity operation (e.g. overnight credit).

In the event that deposits placed for the purpose of efficient cash management are repaid prior to maturity, the National Bank shall recalculate the amount of interest accrued and paid for the period during which the deposit was maintained and shall deduct the resulting difference from the deposit amount to be returned. The recalculation of interest for the above-mentioned deposits repaid prior to maturity shall be carried out by applying an interest rate determined based on the weighted average interest rate in the banking system on demand deposits attracted from legal entities bearing interest in Moldovan lei, available for the last three months preceding each month of maintenance. For deposits placed for the purpose of forming the liquidity reserve and repaid prior to maturity, the initial interest rate on the respective deposit shall not be changed and the interest paid shall not be recalculated.

Dedicated workflows for handling the whole process of the guarantee are required. The National Bank may accept as collateral the following categories of eligible assets: 1) state securities issued by the Government of the Republic of Moldova; 2) certificates of the National Bank of Moldova; 3) deposits and other accounts with the National Bank, including required reserves in foreign currency maintained in unchanged volume or deposits and other accounts with a bank accepted by the National Bank, representing any kind of assets that the National Bank may purchase, sell and negotiate; 4) pecuniary claims, with the exception of claims of the related parties of the bank; 5) corporate securities admitted to trading on the regulated market and/or within a multilateral trading facility (MTF); 6) other financial assets laid down by the National Bank by the decision of the Executive Board.

The approved credit may be disbursed in several tranches (for example, a credit approved in the amount of MDL 10 million may be disbursed in two equal tranches of MDL 5 million each).

At the moment, the National Bank of Moldova doesn’t use any futures products in its present operations just because of the limitations of the actual core system. Nonetheless, the CBS should mandatory offer the possibility of using and maintaining such products.

A trading order refers to a transaction (trade/deal/ticket). These can be of different types, for example: Forex (SWAP, SPOT, FORWARD), term deposits, or buying/selling securities. The main data from the completed transaction (ticket) is loaded from Bloomberg platform into CBS. As about the specific data imported from Bloomberg we can mention the following fields: ticket number, value date, type of operation, currency code, transaction amount, rate, yield, transaction maturity date, dealer’s name, counterparty name, and any other relevant information. The exact data required to be imported from Bloomberg for each type of operation will be discussed in more detail during the analysis and design stage.

For externally managed portfolios CBS should cover the exact same functionality as for the internally managed portfolios with some additional possibilities like backdating and manual registration of the trades reported to the National Bank of Moldova by its external portfolio manager.

1. According to the art.16 (2), from Law on Public Procurement of the Republic of Moldova No. 131/2015, the association is obliged to obtain a certain legal form of organization if this registration is necessary for the proper execution of the contract and only after its award. Thus, at the moment of tender submission it is not mandatory to have an official registration of the association. At the same time, all requirements from tender documents related to the association must be fulfilled. 2. Yes, if the bid is successful, all members of the association will sign the public procurement contract individually, according the provisions form point 19, Annex no.8 to the Participation Notice „Requirements Form”.

1. Yes, the members of the association are jointly and severally liable to NBM as is stated in Participation Notice at the point 19 from Annex no.8 „Requirements Form”. 2. According to the Participation Notice, specifically the provision in the table at point 16 (page 6), “Note: The tender guarantee submitted by the Association must be in the name of the Association submitting the tender.” At the same time, it should be considered that the Economic Operator has the right to either: - submit a single consolidated Tender Guarantee covering both lots, in an amount at least to 1% of the total combined bid value (excluding VAT), or - submit separate Tender Guarantees for each lot, each amounting at least to 1% of the respective lot’s bid value (excluding VAT). Both options are acceptable and will be considered compliant with the tender requirements. Also, Economic Operators should consider that, if they submit bids for both lots, they are required to upload in the MTender system the full set of mandatory documents (at least the six required documents of the bid) separately for each lot. It is to be mentioned, also, that in case of a single consolidated Tender Guarantee, the Economic Operator must consider a possible different timeline for contract award and respectively guarantee return, as this guarantee will cover both lots.

Regarding this question, it is to be mentioned that both parts of the contract: Part I. - the general and standard one and the Part II. - special part of the contract are mandatory for the Tenderers and are not subject to changes, including the payment schedule outlined in Part I. By submitting the tender, the Tenderer confirms agreement with the model contract annexed to the specifications. Thus, the contract model is considered a fixed document and its core clauses, which represent minimum requirements derived from procurement law, cannot be modified. However, additional clauses or agreements may be proposed, if they do not contradict the existing provisions. There is no requirement to submit review comments or proposed changes to the contract model. Instead, bidders may build on top of the contract by adding complementary elements, while respecting the mandatory baseline conditions. Also, the bidder submits, together with the Contract, additional supporting documents such as the Service Level Agreement (SLA), maintenance and support agreement, licensing agreement, and product warranty templates, these documents being considered annexes to the contract.

The requirement regarding complementary licenses is intended to ensure the proper functioning and operability of the proposed solution as a complete and usable system. By complementary licenses, we refer to all necessary software components above the operating system level that are required for the solution to function as designed (e.g., DBMS, application server, or other software dependencies specific to the solution architecture). These do not include infrastructure components, for which the National Bank of Moldova (NBM) remains responsible. The examples provided in the requirement (including DBMS, application server, load balancers, etc.) are indicative and aim to cover scenarios where certain solutions rely on embedded or tightly integrated software components. In particular, the mention of load balancers reflects cases where such functionality is delivered as part of the application stack itself. However, where such components (e.g., load balancing capabilities) are not part of the proposed solution as licensed software, they may be provisioned at the infrastructure level by NBM and therefore are not mandatory to be included as complementary licenses.

With reference to the request to accept global bank references for Lot II, please note that, in accordance with the applicable legal framework governing public procurement in the Republic of Moldova, at this stage of the procedure — while the procurement process is ongoing — the Contracting Authority is not permitted to intervene in the tender documentation in a manner that would result in the modification of the established qualification requirements. Therefore, the qualification criteria as set out in the tender documentation remain unchanged and applicable as published.

Please note that the reference to Annex no. 7 in the RFP documentation should be understood as a reference to Annex no. 8 from the Participation Notice. Kindly consider Annex no. 8 as the Qualification Requirements Form.

The referenced requirements (CNF.104, CNF.105, CNF.106, CNF.107, CNF.115) target application-level capabilities necessary to ensure proper functioning, maintainability, and supportability of the solution. As the solution is required to be turn-key, it must include all necessary mechanisms to support monitoring, diagnostics, alerting, and maintenance at the application level. These requirements refer strictly to capabilities of the solution, not to the provision of enterprise infrastructure tools. NBM acknowledges that enterprise-level monitoring, observability, and infrastructure management tools (e.g., network, server, backup, centralized monitoring platforms) are part of the underlying infrastructure and remain the responsibility of NBM. Therefore, vendors may fulfill these requirements either through native functionalities of the solution or by integrating with standard infrastructure monitoring and observability tools available within NBM.

Requirement CNF.190 is intended to address application-level backup and restore capabilities, which are essential for ensuring data integrity, operational continuity, and recoverability of the solution. Given that the requested solution is a turn-key solution, it is expected to provide all necessary mechanisms to manage backups at the application level. These requirements do not imply the need to provide or replicate enterprise backup infrastructure, which remains under NBM’s responsibility. It is at the vendor’s discretion to integrate the application-level backup mechanisms with NBM’s existing backup infrastructure or provide native application-level tools that facilitate backup and restore processes, compatible with standard infrastructure practices.

Please note that tenderers are required to submit their offers exclusively through the MTender platform. It is recommended that all the requested documents to be uploaded at the time of submission together with the mandatory documents. At the same time, please be informed that each Tenderer is obliged to include in its offer, submitted before the deadline, the following six mandatory documents, duly signed in accordance with the requirements of the tender documentation: 1. Technical Specification (Annex 1 to The Specifications) 2. Price Specification (Annex 2 to The Specifications) 3. ESPD (in case of a consortium, a separate ESPD shall be submitted for each member) 4. Bid Security (minimum 1% of the total tender value, excluding VAT, provided either as a bank guarantee letter or via SWIFT transfer) 5. Detailed Financial Tender for Implementation Services (Annex 3 to The Specifications) 6. Total Cost of Ownership (Annex 4 to The Specifications) Please note that, according to the Participation Notice, point 39.3, provision from the second paragraph „Due to the public nature of the procurement procedure, forms (Technical Specifications, Price Specifications, the ESPD form, and the tender guarantee (where applicable)) will necessarily maintain their public character and cannot be classified as trade secrets or confidential information. Any non-compliance with the above provisions will result in the disqualification of the tender.” The other two documents, namely the Detailed Financial Tender for Implementation Services (Annex 3 to the Specifications) and the Total Cost of Ownership (Annex 4 to the Specifications), only if they contain confidential information and/or are considered commercial secrets, shall be uploaded to the MTender platform in password-protected format. The access password will be communicated to the Contracting Authority after the tender submission deadline, via a separate email sent to achizitii.contracte@bnm.md. All other supporting documents mentioned in RFP will be submitted after the deadline for tender submission, upon request, directly to the Contracting Authority via email (To: achizitii.contracte@bnm.md and in Cc: transform_bnm@bnm.md).

Yes, your understanding is correct.

BNM confirmă că politicile standard de licențiere ale producătorilor (ex. Oracle) trebuie respectate. În acest context, cerința CL.12 trebuie interpretată astfel: • în situația în care, conform politicilor producătorului, licențele trebuie activate/achiziționate la momentul instalării sau utilizării (anterior Go-Live), ofertantul va respecta aceste politici; • toate costurile aferente licențelor pe perioada de implementare (până la Go-Live) vor fi suportate de către ofertant și incluse în ofertă; • la momentul Go-Live, ofertantul va asigura că serviciile de suport și mentenanță pentru licențe sunt valabile pentru o perioadă de minimum 12 luni, astfel încât să acopere perioada de garanție.

Având în vedere cerințele și constrângerile ce reies din procedura de achiziție, Vă comunicăm că BNM nu intenționează să încheie acorduri directe cu producătorii pentru acoperirea fazelor de implementare. Ofertantul este responsabil să asigure toate elementele necesare livrării soluției. În situația în care, conform politicilor producătorului, licențele trebuie activate la momentul instalării/utilizării (anterior Go-Live) și nu există opțiuni de utilizare în regim trial sau echivalent, ofertantul va respecta aceste politici și va include în ofertă costurile aferente perioadei de implementare. Livrarea licențelor poate avea loc înainte de Go-Live, în funcție de necesitățile de implementare, însă facturarea acestora va avea loc exclusiv la etapa de Go-Live, în conformitate cu condițiile de plată stabilite. Ofertantul are libertatea de a propune modele de licențiere conforme cu politicile producătorului (ex. aranjamente temporare, inclusiv încheierea contractelor tripartide, sau alte mecanisme comerciale), astfel încât să gestioneze perioada de implementare. Ofertantul va asigura că, la momentul Go-Live, serviciile de suport și mentenanță pentru licențe sunt valabile pentru o perioadă de minimum 12 luni, acoperind perioada de garanție.

BNM subliniază că mediile de Dezvoltare și Testare sunt medii non-productive, iar așteptarea este ca licențierea propusă să fie adecvată acestui scop și să nu conducă la o creștere artificială a costurilor. În acest context: Ofertantul trebuie să propună un model de licențiere proporțional cu utilizarea non-producție (ex. număr redus de utilizatori, scop de dezvoltare/testare), evitând orice costuri nejustificate. Sunt acceptabile licențe dedicate mediilor de dezvoltare/testare, inclusiv modele pe bază de aranjamente specifice (ex. OTN sau echivalent), cu condiția respectării politicilor producătorului. Cerința de perpetuitate (CL.15) se aplică mediului de producție. Pentru mediile Dev/Test, ofertantul poate propune modele flexibile, adecvate duratei și scopului utilizării.

Pentru a evita o supradimensionare a licenței ofertate, BNM trebuie să dispună de dreptul de a diminua corespunzător numărul de licențe la Go-Live, dacă numărul de facto necesar este mai mic decât cel ofertat. Prin urmare, numărul de licențe perpetue este determinat la nivelul utilizării efective la Go-Live, nu la nivelul maxim ofertat. În situația în care ofertantul include o capacitate mai mare (ex. 100 utilizatori), iar la Go-Live sunt utilizați mai puțini (ex. 60), diferența nu se consideră automat licențiată și respectiv nici disponibilă fără costuri. Activarea ulterioară a unor licențe suplimentare va fi posibilă în baza condițiilor comerciale definite în ofertă (ex. prețuri unitare, mecanisme de extindere). Pentru componente licențiate pe bază de capacitate (ex. Oracle Database per procesor/core), se aplică același principiu. BNM va achita pentru capacitatea efectiv utilizată la Go-Live, iar orice extindere ulterioară se va realiza conform mecanismelor comerciale propuse de ofertant. Referitor la perioada de după Anul 6, TCO acoperă perioada inițială (Anii 1–6). După această perioadă, serviciile de suport și mentenanță vor face obiectul unor negocieri ulterioare, în funcție de condițiile de piață și politicile producătorilor.

Mecanismul la care se face referință a fost prevăzut pentru asigurarea predictibilității costurilor pe întreaga perioadă TCO, prin utilizarea unui model de licențiere bazat pe prețuri unitare transparente și predicitbile. În acest context: • Ofertantul trebuie să prezinte în ofertă un model de licențiere cu prețuri unitare clare, aplicabile pe întreaga perioadă TCO (6 ani), conform cerinței. • Pentru variații rezonabile ale numărului de licențe (în limita ±10% față de nivelul de referință), se va aplica același preț unitar atât pentru creșteri, cât și pentru reduceri, în conformitate cu cerința din TCO. • Protecția de preț ±10% se aplică în raport cu nivelul de referință stabilit (ex. la Go-Live) și este valabilă pe întreaga perioadă prevăzută de TCO. • Pentru variații care depășesc pragul de ±10%, ajustările se vor realiza în baza prețurilor unitare oferite de producătorul licențelor, însă cu menținerea unui mecanism transparent și predictibil. • În cazul în care același ofertant este desemnat câștigător pentru ambele loturi, licențele comune vor fi identificate și deduse o singură dată, pentru a evita dubla licențiere. • Identificarea licențelor comune se va baza pe propunerea ofertantului, fiind validată de către BNM în procesul de contractare, iar deducerea va fi reflectată direct în structura contractuală și financiară.

Ambele centre de date sunt deținute și operate de BNM (on-premise). Nu este prevăzută utilizarea unui centru de date comercial, sau a unor servicii de tip IaaS/PaaS. Arhitectura activ/pasiv a fost aleasă în mod deliberat, având în vedere obiectivele de optimizare a costurilor și a eficienței operaționale, în raport cu cerințele de reziliență și continuitate. Ofertanții trebuie să considere, la nivel de proiectare, o configurație realistă pentru un mediu activ/pasiv. Soluția propusă trebuie să fie flexibilă și adaptabilă la diferite scenarii de replicare (ex. sincronă sau asincronă) și să includă mecanisme adecvate pentru asigurarea RPO/RTO cerute. La moment, banda de transfer disponibilă pentru SAN este de 32 Gb între site-uri, pentru LAN 10 Gbps (care este în proces de modernizare la 100 Gbps), cu o latență sub 5ms, sufiecientă pentru replicarea sincronă a bazei de date. Chiar dacă, infrastructura BNM permite replicare sincronă, ofertanții sunt încurajați să propună arhitectura care oferă cel mai bun raport reziliență/cost, fără a presupune implicit utilizarea unor opțiuni mai costisitoare.

Soluția va fi implementată pe infrastructură on-premise, deținută și operată de BNM, în conformitate cu cerința CNF.54 (VMware pe hardware x86). Nu este avută în vedere, în cadrul acestui proiect, utilizarea unui cloud privat. În ceea ce privește Azure, acesta nu este prevăzut ca parte a arhitecturii CBS/ERP. Mediul Azure al BNM este complet separat de implementarea CBS/ERP. Cerința din CNF.43 privind „cel puțin PaaS” trebuie înțeleasă ca o cerință de aliniere arhitecturală la principii moderne de cloud computing (scalabilitate, modularitate, automatizare, portabilitate), nu ca o obligație ca soluția să ruleze efectiv pe o platformă PaaS.

BNM confirmă că responsabilitățile sunt distribuite între ofertant (proiectare arhitectură, dimensionare și cerințe) și BNM (procurare infrastructură, instalare și configurare până la nivel de SO), cu obiectivul comun de a asigura atingerea nivelurilor de performanță/reziliență stabilite în caietul de sarcini. În acest context: • Ofertantul este responsabil să furnizeze recomandări complete și corect dimensionate de infrastructură (hardware, resurse, configurații), astfel încât soluția să poată atinge cerințele de performanță și reziliență stabilite în caietul de sarcini, în condiții de utilizare normală. • BNM va avea în vedere aceste recomandări în procesul de achiziție/pregătire a infrastructurii. • Recomandările de dimensionare vor constitui referință tehnică în cadrul contractului și vor fi utilizate pentru validarea adecvării infrastructurii, fără a limita dreptul BNM de a ajusta configurațiile, cu condiția menținerii parametrilor minimi necesari și agreării prealabile a acestui fapt cu ofertantul selectat. • În situația în care infrastructura implementată se abate semnificativ de la recomandările propuse de ofertant fără ca acestea să fie coordonate de comun acord, iar acest fapt afectează în mod demonstrabil performanța/ reziliența, responsabilitatea pentru neîndeplinirea SLA-urilor va putea fi atribuită BNM. • BNM dispune de resurse virtualizate suficiente, care pot fi alocate progresiv pe parcursul proiectului, în funcție de necesitățile de implementare. Astfel, mediile necesare (dezvoltare, testare, pre-producție) pot fi asigurate în timp util, chiar și în cazul în care achiziția unor componente hardware suplimentare este în curs. • În ceea ce privește calendarul, achiziția infrastructurii va fi corelată cu etapele de implementare, pe baza recomandărilor ofertantului. • Eventualele întârzieri în livrarea hardware-ului vor avea impact limitat, fiind atenuate prin utilizarea resurselor virtualizate existente, iar acolo unde este necesar, planul de implementare va fi ajustat conform mecanismelor contractuale de gestionare a dependențelor.

Pentru asigurarea unui tratament egal al ofertanților și a comparabilității ofertelor, BNM solicită ca fiecare ofertant să includă în ofertă întregul necesar de licențe complementare pentru soluția propusă, independent de situația curentă a licențierii. Cu titlu informativ, pentru o mai bună înțelegere a contextului existent, comunicăm următoarele: • Licențele Oracle Database aferente sistemelor existente sunt deținute perpetuu de BNM. • BNM deține un contract activ de suport Oracle (Oracle Support Agreement) pentru licențele curente, acestea fiind licențiate în model Named User Plus (NUP). • În cadrul soluțiilor actuale sunt utilizate produsele Oracle Database și Oracle Forms. Totodată, menționăm că, în cazul în care, în cadrul etapei de analiză și design a soluției propuse, se va constata posibilitatea reutilizării anumitor licențe existente, BNM își rezervă dreptul de a solicita diminuarea corespunzătoare a cantității de licențe complementare necesare.

ESB-ul livrat în cadrul proiectului va deveni parte a platformei IT a BNM și va fi deținut și administrat de către BNM după Go-Live. Furnizorul CBS va asigura implementarea, configurarea și transferul de cunoștințe, precum și suportul necesar pe partea sa de responsabilitate (interfețele dezvoltate) în perioada de garanție și, ulterior, în baza unui acord de mentenanță (dacă va fi contractat). Referitor la existența unui middleware de integrare actual, BNM nu dispune de un astfel de sistem și respectiv nu prevede reutilizarea sau înlocuirea unei soluții existente specifice. Migrarea integrărilor existente (în măsura în care acestea sunt necesare pentru funcționarea noului sistem) va face parte din responsabilitatea furnizorului, însă doar pentru integrările relevante în perimetrul soluției ofertate CBS/ERP. Respectiv, nu se așteaptă ca furnizorul să preia sau să migreze în mod exhaustiv toate aplicațiile deținute, ci să implementeze doar integrările necesare conform perimetrului proiectului (a se vedea Anexa 10 pentru interfețele ce urmează a fi implementate).

Este de menționat că la această etapă a procedurii, nu pot fi furnizate specificații tehnice detaliate complete (ex. protocoale exacte, structuri de mesaje, definiții API) pentru toate integrările. În acest context este important de ținut cont cu privire la următoarele aspecte: • Anexa Nr. 10 oferă o viziune de nivel înalt asupra integrărilor necesare, inclusiv sistemele implicate și scopul acestora, constituind baza pentru dimensionarea inițială a soluției. • Suplimentar, în cadrul caietului de sarcini sunt incluse, în mod punctual, cerințe funcționale și tehnice care descriu mai detaliat tipurile de informații și fluxurile ce trebuie asigurate prin aceste integrări. • Specificațiile detaliate (inclusiv formate, protocoale, versiuni, documentație API) vor fi puse la dispoziția ofertantului câștigător în etapa de Analiză și Design, în vederea definirii și implementării integrărilor. • În ceea ce privește protocoalele și formatele de schimb de date, NBM are ca așteptare utilizarea unor standarde deschise și larg adoptate în industrie, cu prioritate pentru: o API-uri standardizate (ex. REST); o standarde specifice sectorului financiar (ex. ISO 20022); o alte protocoale consacrate, acolo unde este justificat. Suplimentar, menționăm că: - Swift: Pentru SWIFT modelul de conectare este SWIFT Alliance Gateway. Da, noul CBS se va conecta la infrastructura SWIFT existentă a BNM. - Bloomberg: Accesam date din Bloomberg prin intermediul protocoalelor SFTP si FIX (Produsele Bloomberg utilizate: SFTP: DATA LICENSE, AUCTIONS PLATFORM FIX: FIXED INCOME, FXGO.

BNM va furniza către CBS parametrii modelului ECL, aceștia putând fi introduși fie manual, fie prin încărcarea unor fișiere (ex. în format Excel). CBS va include un motor propriu de calcul pentru efectuarea calculelor ECL, în conformitate cu metodologia stabilită de BNM, rezultatele fiind generate lunar. În ceea ce privește evaluarea valorii juste, CBS nu necesită, în mod obligatoriu, dezvoltarea unui motor propriu complet de evaluare. CBS poate utiliza date de piață importate din platforme de tranzacționare (ex. Bloomberg), fie automat, fie manual, iar calculul valorii juste se realizează în cadrul CBS, în conformitate cu parametrii și metodologia stabilite de BNM.

Toate înregistrările per tranzacție se efectuează în valuta originală a instrumentului si echivalentul acestuia în MDL la cursul oficial, însă la generarea rapoartelor sa fie si in valuta EUR/USD. - Pentru metale prețioase urmează a fi utilizat prețul aurului stabilit de către BNM pentru ziua respectivă. Prețul este stabilit zilnic pentru un gram de aur fin exprimat în lei moldovenești - Pentru DST urmează a fi utilizat cursul oficial al leului moldovenesc fata de DST stabilit zilnic de către BNM. Cursul DSTMDL este în Lista valutelor străine fata de care BNM cotează leul moldovenesc. - In ziua in care primim ordinul de plata in „alte valute” (valuta in care BNM nu are cont corespondent) de la clientul BNM prin Client-Bank, acesta se importa in sistemul intern BNM si i se atribuie data valutei T+2 (conform cerințelor corespondentului unde BNM are cont multivalutar), respectiv data contabilizării care va fi identica cu data valutei. După autorizările corespunzătoare de către persoanele responsabile BNM, se creează si se exporta in SWIFT Alliance mesajul de tip pacs.008 in „alte valute” originala, care se expediază corespondentului in ziua primirii ordinului de plata. Urmare expedierii mesajului, de la banca corespondenta primim un mesaj de debitare (la moment MT900, ulterior camt.054) a contului cu suma echivalenta in EUR a sumei in „alte valute” expediata, respectiv cu data valutei corespunzătoare. La data valutei, in ordinul de plata din sistemul intern de evidenta, executorul introduce suma in EUR (din mesajul MT900 menționat), echivalentul căreia in MDL va fi egal cu echivalentul in MDL a sumei „alte valute” expediate la cursul oficial din data contabilizării. In cazul in care ordinul de plata in „alte valute” este a BNM-lui, ordinul de transfer se perfectează direct in SWIFT Alliance, conform condițiilor corespondentului descrise mai sus, iar ulterior la data contabilizării, in baza mesajului de debitare (MT900) se perfectează un document contabil in” alte valute” contra valuta contului corespondent prin care a fost efectuat ordinul de transfer respectiv. La moment, plățile in „alte valute” sunt doar in CHF, CAD si NOK.

- Instrumentele de politică monetară utilizate activ de BNM astăzi sunt operațiuni de emitere a certificatelor BNM și repo. În contextul schimbării situației pe piața monetară/deciziilor conducerii BNM/aderării la UE ar putea fi utilizate și celelalte instrumente care includ: tranzacţii reverse repo cu active eligibile; tranzacţii simple (vînzări și cumpărări definitive de VMS); acordare de credite garantate cu active eligibile; atragere de depozite la termen. - BNM nu a acordat ELA, dar instrument foarte similar. - Nu planificam sa avem intervenții umane la transmiterea din CBS in ADPS (CF.86) - Apeluri în marjă sunt efectuate de către Depozitarul Central Unic în conformitate cu art. 77 a Regulilor DCU în vigoare. Astfel apel în marjă se procesează în baza ordinului de plată emis de către DCU.

SAPI (ADPS) operează nativ în formatul ISO 20022 MX, nu este necesara conversia din MT in MX.

La moment BNM deservește cumulativ din numele RM 32 tranșe/facilități de împrumuturi acordate de FMI, după cum urmează: EFF – 14 tranșe, dintre care 6 partajate între BNM și MF și 8 exclusiv contractate de MF; ECF – 14 tranșe, dintre care 2 partajate între BNM și MF și 12 exclusiv contractate de MF; RSF – 3 tranșe, contractate de MF RCF – un împrumut activ contractat de MF. Cursul de schimb DST vs Valuta FX este un curs oficial, publicat zilnic de FMI și disponibil publicului. Conform normei standard a FMI în cadrul tranzacțiilor de conversie (DST vs Valuta) este utilizat cursul din T-2 de la data valutei operațiunii FX. Toate tipurile de inregistrari interne a mesajelor SWIFT intrari/iesiri presupun interventie manuala prin autorizare umana (câteva nivele, minim 2) inclusiv procesarea acestui tip de operațiune, principiu care urmează a fi aplicat și ulterior.

Confirmăm că Bloomberg rămâne platforma de tranzacționare pentru gestionarea rezervelor valutare și generarea tichetelor, în timp ce CBS va asigura decontarea, contabilitatea, evidența și capacitatea de încărcare automată a tichetelor generate de Bloomberg. De asemenea, confirmăm că BNM deține licența Bloomberg Data License, care autorizează extragerea datelor prin API. Pentru simulările pre-tranzacționare, acestea trebuie calculate utilizând motorul intern CBS. În prezent, NBM are 4 portofolii distincte de venit fix (Fixed Income) și un portofoliu de depozite la termen: 1. Portofoliu de venit fix administrat intern, raportat la un benchmark în euro 2. Portofoliu de venit fix administrat intern, raportat la un benchmark în USD 3. Portofoliu de venit fix administrat extern, raportat la un benchmark în USD 4. Portofoliu administrat intern, evaluat la cost amortizat, în EUR și USD 5. Portofoliu de depozite la termen în euro, USD și GBP În același timp, numărul portofoliilor de investiții sau monedele de denominare pot varia în timp.

BNM nu deține statut de participant SEPA Asociatia Bancilor din Moldova este NASO Nu există nici un hub național de transmitere/primire a mesajelor SEPA (aka infrastructură de decontare). Toate băncile sunt conectate individual, indirect. Nici o bancă nu este conectată direct la CSM. În dependență de intermediarul ales, CSM pot fi diferite. Moldova a fost admisă la 3 scheme: SCT, SCTinst, SDD. La moment băncile locale au aderat doar la SCT. BNM va utiliza una din aceste 3 scheme: SCT, SCTinst, SDD, care va fi decisa la etapa de analiza si design. SWIFT Alliance Gateway existent al BNM nu este configurat pentru rutarea SEPA.

- În conformitate cu cerințele BNM referitor la implementarea unui sistem modern și flexibil, așteptarea este ca interfețele să fie standardizate, pe cât posibil, prin API-uri, în linie cu bunele practici moderne de integrare. Soluția trebuie să fie flexibilă și să poată suporta atât integrare prin API-uri (implicit, inclusiv în timp real sau aproape în timp real), cât și schimburi de date de tip batch (ex. pe bază de fișiere), acolo unde este necesar. Deși anumite procese (ex. calcul salarial) pot avea o componentă periodică, există și evenimente operaționale frecvente (ex. acordare concedii, concedii medicale, alte modificări de statut), care necesită schimb de date mai frecvent, motiv pentru care API-urile sunt considerate mecanismul principal de integrare. Schimburile de tip batch pot fi utilizate complementar, acolo unde este justificat, însă nu reprezintă mecanismul implicit. Specificațiile detaliate ale interfeței sistemului de salarizare (formate, structuri de date, protocoale etc.) vor fi puse la dispoziția ofertantului câștigător în etapa de Analiză și Design. - Confirmăm că avantajul acordat salariaților sub forma subvenționării ratei dobînzii la creditele acordate sub nivelul pieței constituie facilitate impozabilă și este reglementată de art. 19 din Codul fiscal al RM. În acest sens: diferența dintre dobânda aplicată și dobânda de piață reprezintă venit impozabil pentru angajat. Acest avantaj urmează a fi determinat, evidențiat și raportat în scopuri fiscal conform legislației fiscale. Astfel, CBS trebuie să asigure: calculul automat al avantajului în natură aferent fiecărui angajat, în baza metodologiei stabilite; cu transmiterea informaţiei către sistemul de salarizare pentru a fi inclusă în baza impozabilă.

CBS trebuie să asigure posibilitatea înregistrării dispozițiilor generate în aplicația Deservirea Rezervelor Obligatorii (DRO) atât în mod automat (fără autorizare), cât și cu autorizare de către persoana desemnată. În prezent, la importul majorității dispozițiilor din DRO în Va-Bank este inclusă etapa de autorizare, iar în cazul unor dispoziții, importul se efectuează automat. În ceea ce privește specificațiile API, este de menționat că la această etapă a procedurii, nu pot fi furnizate specificații tehnice detaliate complete. Specificațiile detaliate (inclusiv formate, protocoale, versiuni, documentație API) vor fi puse la dispoziția ofertantului câștigător în etapa de Analiză și Design. În ceea ce privește SGED, menționăm următoarele: • Conform CI.32, ofertantul va analiza fluxurile existente (inclusiv cele implementate în SGED) pentru a defini o imagine end-to-end a proceselor. • Este important de menționat că utilizarea SGED pentru anumite fluxuri de proces reprezintă, în mare parte, o soluție de tip workaround, determinată de limitările sistemelor actuale. • Așteptarea BNM este ca, prin implementarea noului CBS/ERP, să se asigure consolidarea și automatizarea proceselor în cadrul sistemului principal, evitând fragmentarea acestora între mai multe platforme. • În acest sens, majoritatea fluxurilor de aprobare și procesare vor fi migrate și implementate în CBS/ERP, cu scopul de a asigura un nivel ridicat de automatizare și control integrat. • Pot exista excepții limitate, în special pentru fluxuri complexe sau transversale la nivel organizațional, unde menținerea în SGED (sau integrarea cu acesta) este justificată. • O listă detaliată a fluxurilor va fi pusă la dispoziția ofertantului câștigător în etapa de Analiză și Design, pentru definirea exactă a perimetrului.

1. Audit și aplicarea „dreptului de a fi uitat”: BNM confirmă că înregistrările de audit aferente tranzacțiilor financiare trebuie păstrate integral, inclusiv informațiile privind executorul și cei care au autorizat, pentru a asigura valoarea probatorie și conformitatea cu cerințele legale și de audit. În acest sens, cerințele privind „dreptul de a fi uitat” nu se aplică asupra înregistrărilor de audit ale tranzacțiilor financiare, în măsura în care acestea sunt necesare pentru respectarea obligațiilor legale. Totodată, trebuie avut în vedere că BNM, în mod obișnuit, nu desfășoară relații tranzacționale directe cu persoane fizice, astfel încât aplicabilitatea practică a acestui drept este extrem de limitată. Respectiv, anonimizarea/pseudonimizarea se va aplica, după caz, datelor cu caracter personal non-tranzacționale (ex. date de contact, anumite date operaționale auxiliare), în conformitate cu cadrul legal aplicabil. 2. Migrarea Datelor Așteptarea BNM este ca soluția să asigure continuitatea operațională și comparabilitatea datelor în perioada de tranziție. În acest context: • Se așteaptă ca toate datele master (ex. entități, conturi, nomenclatoare) și tranzacțiile active, împreună cu istoricul aferent acestora, să fie migrate integral în noul CBS/ERP. • Suplimentar, se prevede migrarea unei perioade relevante de date istorice, necesară pentru raportare, reconciliere și comparabilitate în perioada post Go-Live. • Pentru restul datelor istorice, nu se impune migrarea integrală în noul sistem. Acestea pot rămâne disponibile în sistemele existente, care vor fi menținute de către BNM în scopuri de raportare și consultare. • Strategia detaliată de migrare (volum, perioade, mecanisme tehnice, arhivare) va fi definită și agreată de comun acord între părți în etapa de Analiză și Design, în funcție de complexitate, riscuri și constrângeri operaționale.

Reieșind din faptul că aspectele legate de strategia de Go-Live (ex. big bang, rularea paralelă, mecanismele de rollback etc.) pot avea un impact major asupra succesului implementării, cerințele din caietul de sarcini prevăd ca ofertantul, reieșind din expertiza și experiența sa, să propună o viziune cu privire la aceste aspecte. Astfel, BNM nu impune o abordare predefinită pentru aceste elemente, însă se așteaptă ca abordările propuse să fie justificate din perspectiva reducerii riscurilor operaționale și a continuității activității. Deciziile finale privind strategia de Go-Live, rularea paralelă, criteriile de rollback, scenariile de testare și calendarul de implementare vor fi stabilite de comun acord în etapa de planificare detaliată, pe baza propunerii ofertantului, constrângerilor operaționale ale BNM, analizei detaliate a riscurilor și dependențelor, precum și a altor elemente relevante. Toate aceste aspecte vor fi analizate și agreate în mod colaborativ, cu implicarea tuturor părților relevante, astfel încât soluția finală să reflecte un echilibru optim între risc, cost și complexitate operațională. Referitor la testarea performanței (CNF.88): • scenariile de test, profilurile de utilizare și nivelurile de concurență vor fi definite și agreate în etapa de Analiză și Design, conform cerințelor din caietul de sarcini; • pentru testele de performanță, este considerată adecvată utilizarea seturilor de date sintetice, care pot simula volumele și tiparele reale de utilizare; • ofertantul va pune la dispoziție instrumentele și expertiza necesare pentru generarea acestor seturi de date, inclusiv pentru definirea scenariilor de test relevante; • BNM va contribui, acolo unde este necesar, cu informații privind profilurile de utilizare și volumele operaționale, pentru a asigura relevanța testelor.

Cu privire la solicitarea de extindere a termenului limită de depunere a ofertelor, vă informăm că aceasta va fi analizată de către Grupul de lucru pentru achiziții al BNM, ținând cont de complexitatea proiectului, de necesitatea asigurării principiului concurenței, precum și de respectarea cadrului legal aplicabil. În cazul în care vor fi operate modificări ale termenului limită de depunere a ofertelor, acestea vor fi comunicate tuturor operatorilor economici prin intermediul platformei MTender, în condiții de transparență și tratament egal.

1. The Human Resources management module is out of scope of this project. For Lot II (ERP) and CBS it is expected that the proposed solution has interfaces to import from the HR system only the necessary employee/user-related metadata required to support system functionality and integrations. A full HR module (including functionalities such as leave management, time tracking, or comprehensive employee lifecycle management) is not required. 2. It is intended that the ERP system will fully replace the current Budget application. 3. A dedicated software solution (out of scope) is planned for canteen management, with simplified integration into the ERP system. The management of rest house and transport services is expected to be handled within the ERP system, to the extent supported by its native functionalities in a simplify manner (described in the RFP). NBM has a limit number of transport units (up to 15). 4. The procurement process will continue to be conducted through the M-Tender platform in accordance with public procurement regulations. Within the ERP system, it is planned to support the preparation and monitoring of the procurement plan, ensuring its alignment with the approved budget and tracking its execution. 5. Public procurement is carried out based on the approved budget, and therefore the system should support appropriate budget control and commitment mechanisms. The administrative operating expenditure budget is prepared and executed on an accrual basis, and the ERP should support commitment accounting for this category. At the same time, the administrative investment budget for long-term assets is executed on a cash basis, and the ERP should be able to accommodate this approach accordingly. 6. All budget categories should ideally be: - Managed within a unified ERP structure, - Differentiated using analytical dimensions, - With distinct workflows and access controls applied as needed. This approach ensures flexibility and scalability while avoiding system fragmentation. 7. Yes, NBM applies IFRS 16 Leases, and the solution should support full lease accounting in respect of the provisions of IFRS 16, including the right-of-use asset recognition, lease liability and interest amortization, as well as subsequent modifications to lease contracts. However, the NBM has few number of ongoing lease contracts. 8. Yes, shared overhead costs are intended to be allocated across organizational units. There is currently no finalized cost accounting process in place. The approach will depend on the capabilities of the selected system, provided that it supports managerial cost reporting and allocation of shared costs. Allocation keys and related rules will be defined during the design and configuration phase. The solution should allow NBM administrators to configure and adjust allocation rules without vendor intervention, using the standard functionalities of the selected module. 9. The approximate number of cost centers and profit centers is currently under determination. This information will be defined and confirmed during the analysis and design phase of the project. At present, NBM consists of 26 subdivisions, structured across multiple organizational units, with over 30 operational processes.

În conformitate cu prevederile documentației de atribuire, și anume Anunțul de participare și Anexa nr. 8 – „Formularul cerințelor de calificare”, Ofertantul nu este limitat în a propune aceeași echipă de proiect pentru implementarea soluțiilor informatice aferente ambelor loturi. Acest lucru este permis cu condiția respectării tuturor cerințelor referitoare la numărul de experți-cheie și la criteriile de calificare ale acestora, precum și a asigurării respectării parametrilor de timp și calitate solicitați prin documentația de atribuire și oferta depusă.

Oferta depusă va cuprinde în mod obligatoriu cele 6 documente enumerate în Anunțul de participare și anume: Specificația de preț, Specificație tehnică, formularul DUAE (în cazul unei asocieri, va fi depus formularul DUAE pentru fiecare membru), Garanția pentru ofertă (scrisoarea de garanție bancară sau dova transferului prin SWIFT), Detalierea ofertei financiare pentru serviciile de implementare (Anexa nr. 3 la Caietul de sarcini), Costurile totale de deținere TCO (Anexa nr.4 la Caietul de sarcini). Totodată, în conformitate cu art.65 alin.(4) din Legea privind achizițiile publice nr.131 din 03.07.2015, prezentarea ofertei presupune depunerea într-un set comun, în mod obligatoriu, a propunerii tehnice (Specificația tehnică), propunerii financiare (Specificația de preț), formularul DUAE și garanției pentru ofertă la data deschiderii ofertei. Datorită caracterului public al procedurii de achiziție, formularele (Specifcații tehnice, Specificații de preț, Formularul DUAE și garanția pentru ofertă) își vor păstra obligatoriu caracterul public și nu poate fi clasificat ca secret comercial sau informație confidențială. Orice nerespectare a prevederilor de mai sus determină descalificarea ofertei. În cazul în care, celelalte două documente obligatorii aferente ofertei, precum Detalierea ofertei financiare pentru serviciile de implementare, Costurile totale de deținere (TCO), documentele de calificare și selecție dacă conțin informații confidențiale și/sau sunt atribuite la secretul comercial, în vederea protejării proprietății intelectuale și/sau a datelor cu caracter personal, în vederea respectării art.17 alin (2) din Legea nr.131/2015, se vor încărca în sistemul MTender ca fișiere parolate. Ulterior expirării termenului limită de depunere a ofertelor, Ofertantul, va transmite printr-un email parola către autoritatea contractantă, la adresa: To: achizitii.contracte@bnm.md.