Short answer
A shared lender database can support Latvian creditworthiness assessment and credit-risk management, but the permission is bounded. The Credit Institutions Law and Credit Information Bureau Law identify eligible participants, purposes, sources and responsibilities. They do not create a general right for competing lenders to exchange everything useful to them.
The competition-law boundary is lender strategy. The system should not reveal, directly or by inference, a rival's current or future pricing, acceptance thresholds, risk appetite, application pipeline, approval rates, customers, product volumes or planned conduct. A neutral bureau and an “aggregate” label are not enough if a small group, narrow category or sequence of queries lets participants reverse-engineer contributor data. A Latvian Competition Council decision specifically prohibited category-volume exchange where only one or two participants made sales.
The data-protection boundary is the individual. Borrower and guarantor data require a defined lawful basis, a statutory credit purpose, minimisation, accuracy, transparency, retention limits, security and effective rights. Pseudonymised data remain personal data. Solely automated denials or limit decisions may trigger GDPR Article 22 safeguards.
The sound architecture therefore separates borrower-level credit records from market analytics, suppresses small cells, limits access by role and purpose, logs every query, preserves provenance and disputes, and prevents the database from becoming a competitor-intelligence service.
The permission comes from a narrow statutory function
Latvia does not begin from a blanket prohibition on lender information sharing. Section 106(4)–(6) of the permits specified financial institutions and insurers to exchange information about debtors or guarantors, their obligations and performance, directly or through a special institution. Consumer-related exchange operates under the Consumer Rights Protection Law, while specified lender exchange about legal persons is routed through a credit information bureau.
The then defines a regulated system rather than an open commercial data pool. Section 4 confines ordinary access and use to assessing a customer or prospective customer's creditworthiness or managing the user's own credit risk:
Kredītinformācijas lietotājs kredītinformāciju no kredītinformācijas biroja … iegūst un izmanto klienta vai iespējamā klienta kredītspējas vērtēšanai vai sava kredītriska pārvaldībai.
—
That purpose boundary should be built into the product. An authenticated lender account is not enough. A query should be connected to an identified application, customer relationship or own-credit-risk task. Marketing, employment screening, curiosity searches and competitor benchmarking do not become lawful merely because the same technical platform could perform them.
Section 6 limits permissible source categories; public availability is not a licence to ingest every accessible dataset. Sections 18 and 21 also require a lawful basis and the statutory purpose.
Statutory sharing does not remove competition law
Section 11 of the prohibits agreements and concerted practices whose object or effect restricts competition. The text expressly reaches exchanges concerning prices or sales conditions. Its efficiency route is demanding: the arrangement must produce objective gains, allow consumers a fair share, impose only indispensable restrictions and preserve competition; the party relying on that route bears the burden.
The lawful exchange of a borrower's repayment history does not justify disclosing lender strategy. The two data layers answer different questions:
- A borrower record helps a lender assess whether that person or company is likely to perform its obligations.
- Lender-performance data can tell rivals how another lender prices, approves, rejects, segments customers, changes appetite or plans to compete.
Only the first may fall within the specialised credit-information regime; the second requires a separate competition analysis.
The explains the underlying independence principle. Contacts are problematic where their object or effect is to influence a competitor or reveal intended conduct:
ir aizliegti jebkuri kontakti starp tirgus dalībniekiem, kuru mērķis vai sekas ir ietekmēt esošā vai potenciālā konkurenta rīcību tirgū
—
That principle reaches more than a field named “price.” Approval cut-offs, offered limits, risk thresholds, customer migration and portfolio changes may reveal competitive behaviour just as effectively.
A neutral intermediary does not make granular data safe
The Council's is particularly useful for database design. Competing wholesalers exchanged detailed sales indicators, including through an association. The Council's forward-looking order prohibited exchange of product-category sales volumes where only one or two participants made sales:
neapmainīties ar pārdošanas apjomiem tajās produktu kategorijās, kurās pārdošanas apjomi ir tikai vienam vai diviem no apmaiņas dalībniekiem
—
That warns against cosmetic aggregation. One contributor is identifiable; with two, a lender that knows its own figure can often derive the other's. Repeated or overlapping queries can create the same problem.
A shared lender platform should therefore apply meaningful minimum contributor counts, suppress narrow cells, use reporting delays where relevant, prevent differencing attacks and test whether participants can combine outputs with their own knowledge. The administrator's independence helps governance, but it does not cure an output that remains strategically revealing.
The GDPR applies to borrower and guarantor data
Section 3 of the Credit Information Bureau Law expressly preserves the GDPR and Latvia's Personal Data Processing Law to the extent the special Act does not provide otherwise. The laws operate together.
For natural-person borrowers and guarantors, GDPR Article 5 requires lawful, fair and transparent processing; purpose limitation; data minimisation; accuracy; storage limitation; security; and accountability. Article 6 requires an identified lawful basis and necessity for the particular processing. A lender or bureau should not treat “credit scoring” as a basis in itself.
The minimisation rule is concise:
adequate, relevant and limited to what is necessary
—
Each field therefore needs justification. It should serve the permitted credit purpose, come from an allowed source, be accurate and be retained only as long as the governing rule and purpose permit. The database also needs the correction and dispute workflow required by Latvian law.
Company credit is not automatically outside the GDPR: sole traders, directors, beneficial owners and personal guarantors may still be identifiable individuals.
Transparency and automated decisions need their own controls
GDPR Articles 13 and 14 require intelligible information about the controller, purposes, legal basis, recipients, retention and rights. Article 14 also addresses the source of indirectly obtained data. Notices should distinguish the lender's assessment from the bureau's collection and disclosure functions.
Article 22 becomes relevant when a denial, credit limit or similarly significant outcome is based solely on automated processing. Applicable safeguards can include human intervention, an opportunity to express a view and the ability to contest the decision. A rubber-stamp review is not meaningful human decision-making.
Pseudonymisation does not switch these duties off. If the participant or administrator can reconnect a record to an individual using additional information, it remains personal data. Claims of anonymisation require a realistic assessment of singling out, linkage and inference—not just removal of a name.
A defensible architecture
A shared lender database should be designed as two deliberately separated environments.
The borrower-record environment should contain only authorized source categories and fields needed for a documented creditworthiness or own-risk purpose. It should use role-based access, purpose capture at query time, provenance and effective dates, dispute flags, correction propagation, retention controls and immutable access logs. Where the Latvian statute requires the contributing user's identity not to be disclosed, the data model and interfaces must enforce that rule.
Any market-statistics environment needs a separate competition assessment. It should exclude current or future contributor strategy, use sufficiently large aggregation groups and time lags, suppress small or sparse cells, prevent repeated-query reconstruction, and prohibit exports that permit lender-level benchmarking. The design review should consider market concentration, number of contributors, frequency, field sensitivity, recipient group and what each recipient already knows.
Across both environments, governance should include written field and purpose inventories, authenticated recipients, least-privilege access, clear controller and processor roles, security and audit controls, effective individual-rights routes, testing of automated outcomes, a data-protection impact assessment where high risk is likely, and competition review before launch or material changes.
What the indexed sources can and cannot establish
The production MCP supplied the current statutes, GDPR provisions and full decisions used here. Its 1,117 Competition Council records mean these examples are representative, not an exhaustive clearance standard.
The indexed Datu valsts inspekcija collection remains only four selected English-language guidance pages. It does not support a claim that the Latvian regulator has approved a specific shared-lender architecture. Existing tracks that coverage boundary.
An exact-identifier defect also recurred: searching LV-KP-211 returned 50 unrelated approximate matches and omitted the record, although that string is its title and case number. A Latvian phrase found it at rank one. Evidence was added to ; tracks a separate decision-kind mapping defect.
Conclusion
Latvian law permits a bounded credit-information function; it does not authorize a shared window into competitors' strategies. A compliant design keeps borrower assessment separate from lender analytics, admits only justified data and users, prevents contributor identification, enforces individual rights, and tests both direct and inferential disclosure. The decisive question is not merely whether the database has a legal basis, but whether every field, query and output remains necessary for the permitted credit purpose without reducing competition between its participants.
Sources
This article provides general legal information, not advice for a specific matter. Laws, facts and procedural deadlines may change the result. Follow the linked primary sources and obtain local advice before acting.