1. Executive summary
Use Lovable to finish the investor MVP on demo data, but build the production platform for real banks as a custom application on EU-hosted managed cloud, starting before the first pilot.
A bank that puts Banksource in its DORA register of ICT providers will ask for evidence of security controls, audit logs, exit options and subcontractor transparency. A generated-code platform cannot easily supply that evidence.
What changed from version 1
- Lovable's drawbacks are stated plainly (Section 4), including a published row-level-security vulnerability class and limited control over infrastructure and releases.
- Custom development is spelled out (Section 5) as the route to scale: control over architecture, hosting region, testing, CI/CD, observability and exit.
- A new EU regulatory section (Section 7) maps DORA, GDPR, NIS2, the EBA outsourcing guidelines, the AI Act and related rules to platform requirements.
- A hybrid roadmap keeps MVP momentum without a throwaway rebuild: the Lovable front end becomes a clickable specification and the production system reuses its data model and workflows.
Nothing here is legal advice. Confirm regulatory claims with qualified counsel before signing any contract with a financial institution.
2. Project overview
Banksource is a B2B SaaS platform that brings vendor discovery, procurement, contract management, third-party risk assessment and regulatory reporting into one application for European banks, insurers, asset managers and IT vendors. The same data that supports sourcing also feeds a bank's DORA register of information and risk reporting.
| Portal | Users | Core functions |
|---|---|---|
| Bank | Procurement, risk, legal, compliance and audit teams | Vendor discovery, RFx and tenders, contract lifecycle, risk assessments, audit reporting |
| Vendor | IT and service providers | Company profile, compliance passport, tender responses, contracts, certification tracking |
| Administration | Banksource staff | Access approval, role assignment, suspension, platform administration |
The existing MVP already has database-backed login, roles, vendor records, tender submissions and compliance passports. Several screens, including AI contract analysis, still use static sample data.
3. What we will build
The functional scope is unchanged from version 1. What changes is how it is built and evidenced (Sections 5 to 8).
Authentication and user management
- Invite-only registration with administrator approval, separate bank and vendor accounts, password reset, suspension and reactivation.
- Mandatory MFA for institutional users, SSO (SAML and OIDC) for banks, and administrator rights held separately from ordinary roles.
- Access enforced in the backend and database, never only by hiding pages.
Bank portal
- Command Centre: vendor, tender, contract and risk overview, DORA readiness indicators, concentration-risk view, configurable widgets.
- Vendor Marketplace: search and filter by category, location and certification; read-only compliance passports; shortlists.
- RFx and tenders: RFI, RFP and RFQ workflows, questionnaires, deadlines, vendor Q&A, weighted bid evaluation.
- Contract intelligence and lifecycle: repository, clause comparison, gap tracking, expiry and notice-period alerts, approvals.
- Risk management: third-party and contract risk across cybersecurity, privacy, sustainability and other domains, with controls, evidence and history.
- Audit and reporting: structured reports, Excel and PDF export, immutable audit trail, DORA register-of-information export and GDPR templates.
Vendor portal
- Company profile, compliance passport (frameworks, certifications, expiry dates), publishing controls, tender submissions, contract actions and a deadline dashboard.
- Vendors edit only their own records; banks see only published passports.
Administration panel
- Access-request review, approval, rejection, suspension, role assignment and platform-admin privileges, all logged, with four-eyes approval for privileged changes.
4. Lovable: strengths and drawbacks for a regulated product
Lovable is the right tool for the investor demo and a poor foundation for a system banks will rely on. The speed that suits a demo becomes a liability once real institutions, confidential contracts and supervisory scrutiny are involved.
Where Lovable helps
- Fast iteration on screens and workflows, with stakeholder feedback within days.
- Managed database and authentication with almost no server administration.
- The current MVP already exists on it, so continuing avoids rework until the demo is done.
Drawbacks that matter for banking
| Drawback | Why it matters for Banksource |
|---|---|
| Security depends on generated database policies | Apps built with Lovable and Supabase have repeatedly shipped with missing or wrong row-level security. CVE-2025-48757 (CVSS 9.3) allowed unauthenticated reads and writes on tables of generated sites, and researchers reported 170+ affected apps. Lovable's position is that customers remain responsible for correct policies. In a multi-tenant bank product, one wrong policy exposes another bank's contracts. |
| Client talks directly to the database | The generated front end calls the database API from the browser with a public key, so every table and policy is an internet-facing attack surface instead of sitting behind a controlled API layer. |
| Limited control of infrastructure and releases | A bank's DORA assessment asks about hosting region, network isolation, change management, patching, incident handling and exit. Platform-managed hosting gives little to configure and little to evidence. |
| Lock-in and an extra subcontractor | Lovable and its backend provider become ICT subcontractors that every customer must record and assess in its register of information. Exit plans must cover them too. |
| Code quality and maintainability | Generated code tends to mix presentation, business rules and data access. Tender evaluation, approvals and audit trails become hard to test and change safely. |
| Weak testing and environments | Regulated software needs unit, integration and security tests, separate dev, staging and production environments, and traceable releases. None are built in. |
| Audit trail and observability | Immutable audit logs, monitoring, alerting and incident evidence must be built on top, and the platform limits where they can sit. |
| Scale and cost predictability | Usage-based pricing and platform limits are hard to forecast with large document volumes and AI processing. |
| Compliance evidence is not inherited | Platform certifications, where they exist, do not certify the Banksource application itself. |
The conclusion is not to abandon the MVP. Treat the Lovable build as a validated prototype and keep real bank data, real contracts and any live vendor data out of it.
5. What custom development provides for long-term scale
A custom application gives Banksource control over the things a bank will audit and the things that decide cost and speed at scale. Version 1 treated this as a later option. It is now the recommended production path.
| Capability | What custom development provides | Benefit at scale |
|---|---|---|
| Security architecture | All data access passes through an API layer with central authorisation. Row-level security stays in PostgreSQL as a second line of defence. | One audited place for permissions; far lower risk of cross-tenant leaks. |
| True multi-tenancy | Organisation, membership, role and entitlement model designed first. Shared schema, schema-per-tenant or dedicated database for large banks. | Isolation tiers for large institutions without rewriting the product. |
| EU hosting and residency | Choice of EU region, provider and encryption-key ownership (customer-managed keys). | Meets bank data-location and exit requirements; supports sovereign-cloud demands. |
| Engineering quality | Typed codebase, automated unit, integration, end-to-end and security tests, code review, dependency scanning. | Safe, fast change as the team grows; evidence for bank due diligence. |
| CI/CD and environments | Separate dev, staging and production, infrastructure-as-code, signed builds, rollback. | Traceable releases that satisfy change-management controls. |
| Observability and audit | Structured logging, tracing, alerting, tamper-evident audit trail, SIEM export. | Faster incident response and the evidence DORA incident reporting needs. |
| Resilience | Multi-zone deployment, tested backups and point-in-time recovery, defined RTO and RPO, documented exit plan. | Credible answers to bank resilience and exit questionnaires. |
| Enterprise integration | SSO, SCIM provisioning, REST and webhook APIs, ERP, GRC and ticketing connectors, queue-based processing. | Banks can embed Banksource in existing processes. |
| Document and AI pipeline | Virus scanning, text-extraction workers, queue, model-provider abstraction, human review, per-tenant usage limits. | Controlled cost and swappable AI providers. |
| Performance and cost | Caching, background jobs, indexed reporting views, usage metering. | Predictable cost per tenant as document volume grows. |
| Ownership and exit | Code, infrastructure and data under Banksource's accounts; portable stack (PostgreSQL, containers, S3-compatible storage). | No provider lock-in; simpler to describe in customers' exit plans. |
What it costs. More engineering time, a larger upfront budget, and ongoing maintenance of infrastructure and patching. Managed services (PostgreSQL, container platform, identity) keep this manageable, and it is the normal cost of selling to regulated institutions.
What carries over from the MVP. The data model, user flows, screens and validated workflows. The Lovable build becomes the specification and the demo, so this is a controlled migration, not a restart.
6. Platform options and recommended path
Hybrid path: Lovable for the demo, a custom build for the pilot and production. Self-managed VPS hosting is not recommended at any stage, because patching, backups and availability would become Banksource's own regulatory burden.
| Option | Best for | Main limitation | Verdict |
|---|---|---|---|
| 1. Lovable + Lovable Cloud | Investor demo, clickable prototype | Limited control, security by generated policy, extra subcontractor | Demo only, no real bank data |
| 2. Lovable + dedicated Supabase | Extended MVP with managed backend | Still generated code and browser-to-database access | Closed pilots with synthetic data only |
| 3. Custom app on managed EU cloud | Pilot with real banks, production SaaS | More engineering effort | Recommended production path |
| 4. Dedicated EU environment per customer | Large banks with sovereignty or isolation demands | Highest cost and operations load | Premium tier later, same codebase |
Recommended stack for option 3 (confirmed in the technical audit)
- Frontend: React and TypeScript (Next.js), reusing the MVP's design system.
- Backend: NestJS (Node.js, TypeScript) or FastAPI (Python); a modular monolith first, services only when justified.
- Database: managed PostgreSQL in an EU region, with row-level security as defence in depth.
- Identity: managed identity provider with MFA, SSO (SAML and OIDC) and SCIM.
- Storage: private S3-compatible object storage with customer-managed encryption keys.
- Queue and workers: document processing, notifications and AI jobs.
- Infrastructure: containers, infrastructure-as-code, CI/CD with automated tests and security scans.
- Observability: central logs, metrics, tracing, uptime checks and SIEM export.
Environments. Development, staging and production stay separate. Investor-demo data, test data and real bank data never share an environment.
7. EU regulatory framework for the platform
Banksource will be an ICT third-party service provider to regulated financial entities, so DORA drives most requirements, followed by GDPR and the rules on outsourcing and cyber security. Position as of 14 October 2026. Counsel must confirm applicability and national transposition before the first bank contract.
Why DORA comes first. Every bank using Banksource must record it in its register of information, which covers all ICT third-party contractual arrangements, including subcontractors. The register goes to the national supervisor and is used by the European supervisory authorities to designate critical ICT providers. Banksource is unlikely to be designated critical, but it will be assessed like any provider supporting important functions, and the mandatory contract content in Article 30 applies to its contract.
| Regulation or standard | How it applies to Banksource | What the platform must provide |
|---|---|---|
| DORA, Regulation (EU) 2022/2554, applied from 17 January 2025 | Banksource is an ICT third-party provider to every bank, insurer and asset-manager customer. Customers need evidence for due diligence, the register of information and exit planning. | ICT risk management framework; incident detection and customer notification; resilience testing; backup and recovery with tested RTO and RPO; documented subcontractors; audit and access rights; exit and data-return plan; Article 30-compliant contract terms. |
| GDPR, Regulation (EU) 2016/679 | Processor for customer data (contacts, contract signatories, user data); controller for its own account and marketing data. | Data processing agreement (Art. 28); security of processing (Art. 32); records of processing; breach notice to customers without undue delay so they can meet the 72-hour rule; DPIA support; sub-processor list; data-subject request tooling; transfer safeguards (Chapter V) if data leaves the EU. |
| EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) | Banks apply them to cloud and outsourced services; ICT aspects now overlap with DORA. | Support bank due diligence, audit rights, sub-outsourcing controls, data location and termination rights. |
| NIS2, Directive (EU) 2022/2555 | Banks fall under DORA as the specific rule. Banksource itself may be in scope as a digital or managed-service provider, depending on size and national law. | Risk management measures, supply-chain security, incident reporting, management accountability. |
| EU AI Act, Regulation (EU) 2024/1689 | Applies to Banksource as provider and to banks as deployers of the contract-analysis features (Section 10). | AI literacy, transparency notices, human review, classification record; no use for credit scoring or employment decisions. |
| EU Data Act, Regulation (EU) 2023/2854 | Cloud and data-processing services must support customer switching and data portability. | Documented export formats, switching process and fair exit terms. |
| Cyber Resilience Act, Regulation (EU) 2024/2847 | Covers products with digital elements. Pure SaaS is generally outside it, but a downloadable agent or connector could fall inside. | Confirm scope with counsel; adopt secure-by-design and vulnerability handling regardless. |
| ePrivacy and cookie rules | Marketing site banksource.eu and any analytics. | Consent banner; no tracking before consent. |
| ISO/IEC 27001, 27017, 27018, ISO 22301; SOC 2 Type II | Voluntary, but banks routinely ask for them in procurement. | Plan ISO 27001 first; SOC 2 Type II when customers require it. |
What DORA means for the contract
Banks will expect a clear description of services, the locations where data is processed and stored, data protection and return of data on termination or insolvency, service levels, assistance during ICT incidents, cooperation with supervisors, termination rights, participation in security training and, for important functions, audit and access rights and an exit strategy. Banksource should hold a standard contract and security annex covering these from the first pilot.
Product features that support the customer's duties
The vendor passport, contract-clause comparison and risk assessments should map to DORA Article 30 content, and the platform should export data in the structure required for the register of information. These are decision-support features. They help a bank prepare evidence; they do not make the bank or its vendor compliant.
Regulatory watch list. The Digital Omnibus changed AI Act deadlines in 2026 and also amended parts of the GDPR, and national NIS2 transposition varies by country. A quarterly regulatory review belongs in the support plan.
8. Target architecture, multi-tenancy and security
Security is an architecture requirement, and the organisation layer must exist before the first real bank is onboarded. In the MVP, bank-side records belong to the individual user who created them. In a bank, colleagues must share tenders, contracts, shortlists and risk assessments.
How a request is handled
- The user signs in through the identity provider with MFA or bank SSO.
- The API verifies the session, the account's approved status, its role and its organisation membership.
- The API checks the action against the organisation's permissions and entitlements.
- PostgreSQL returns only that organisation's rows, enforced again by row-level security.
- Sensitive operations run in server-side workers, never in the browser.
- Files are served only through short-lived, authorised links from private storage.
- Every sensitive action writes to an append-only audit log, and logs feed monitoring and alerting.
Multi-tenant data model
organizations(banks, insurers, vendors),memberships, organisation roles and entitlements.- Tenders, contracts, shortlists, risk assessments and documents scoped to the organisation, not the user.
- Cross-tenant tests in CI that fail the build if one organisation can read or write another's data.
- Option to place large banks on a dedicated database or environment later.
Security controls
| Area | Control |
|---|---|
| Identity | MFA required; SSO via SAML and OIDC; SCIM provisioning; session limits; privileged admin access with four-eyes approval. |
| Data protection | TLS 1.2 or higher in transit; AES-256 at rest; customer-managed keys for enterprise tenants; field-level encryption for the most sensitive records. |
| Application | Input validation, output encoding, rate limiting, CSRF and SSRF protection, secure file upload with malware scanning, OWASP ASVS as the test baseline. |
| Secrets | Central secrets manager; no keys in code or the browser; rotation policy. |
| Audit | Append-only trail of logins, permission changes, document access and exports; retention agreed per customer. |
| Monitoring | Central logs, anomaly alerts, uptime checks, incident runbooks and customer notification aligned with DORA. |
| Resilience | Multi-zone deployment, encrypted automated backups, point-in-time recovery, quarterly restore tests, documented RTO and RPO. |
| Supply chain | Dependency and container scanning, signed builds, software bill of materials, subcontractor inventory. |
| Assurance | Annual external penetration test, internal security review before each release, vulnerability disclosure policy. |
9. Hosting, data residency and subprocessors
Host production in an EU region of a major managed cloud, or an EU-headquartered provider where a customer requires it, and keep all customer data, backups and logs in the EU. A European location alone does not establish compliance, so each provider is assessed on contract terms, subprocessors, support-staff access from outside the EU and exit options.
| Decision | Recommendation |
|---|---|
| Region | EU only for production data, backups, logs and AI processing; named region per customer in the contract. |
| Provider | Shortlist AWS, Microsoft Azure, Google Cloud and one EU-headquartered provider; decide on customer demand, DORA contract terms, key-management options and cost. |
| Encryption keys | Customer-managed keys for enterprise tenants; documented process for provider access requests. |
| Third-country access | Assess non-EU parent-company and support access; document transfer safeguards and legal basis before any transfer. |
| Subprocessors | Public list, with advance notice to customers of changes. |
| Environments | Separate cloud accounts or projects for development, staging and production, with restricted production access. |
| Exit | Portable stack and documented export, so customers can include Banksource in their own exit plans. |
The provider inventory (cloud, identity, email, monitoring, AI) is a deliverable in its own right, because banks will copy it into their register of information. Monthly costs depend on users, database size, document storage, traffic, backups, monitoring and AI usage, and should be estimated after the technical audit instead of quoted as fixed server prices.
10. AI and contract intelligence
AI contract analysis is decision support. It extracts and flags, and a qualified person decides. The current demo uses static examples, so real AI functionality is a separate stage after the multi-tenant and security foundation.
Workflow
- An authorised user uploads a contract; the file is validated, virus-scanned and stored privately.
- A worker extracts the text and sends it to the AI service under the tenant's settings.
- The model identifies clauses, dates, obligations and possible gaps against an agreed set of DORA Article 30 and customer-specific requirements.
- Results are stored with source references, model version, confidence and processing status.
- A qualified reviewer accepts, edits or rejects each finding before it affects any record.
Regulatory guardrails
- AI Act timing. The Digital Omnibus moved high-risk obligations for stand-alone systems to 2 December 2027, while Article 50 transparency obligations and general-purpose AI enforcement stayed at 2 August 2026. AI literacy and prohibited-practice rules already apply.
- Classification. Contract clause analysis is not expected to be high-risk. Features that influence creditworthiness, employment or similar Annex III uses would be, so they stay out of scope. Record the classification reasoning for each AI feature.
- Transparency. Label AI-generated output in the interface and in exports.
- Human oversight. No automatic compliance verdicts or vendor rejections.
- GDPR. Provider contract with processor terms, no training on customer data, defined retention, EU processing region and a DPIA before launch.
- Confidentiality. Tenant isolation applies to AI prompts, embeddings and caches.
- Provider independence. A provider-agnostic layer so the model can be swapped if terms, location or cost change, and so customers can opt out of AI.
- Cost control. Per-tenant usage limits and metering before general release.
- Quality. A labelled test set of contracts, measured precision and recall, and regression tests when the model changes.
11. Roadmap and milestones
The roadmap runs two tracks: finish the demo quickly on Lovable, and start the production platform immediately so the pilot does not run on the prototype. Dates are set after the technical audit. Each phase ends at a gate that must pass before the next begins.
| Phase | Scope | Gate to pass |
|---|---|---|
| 1. Audit and architecture | Review the Lovable project and repository; list live versus demo-data features; confirm data model, tenancy model, hosting provider and regulatory scope with counsel. | Signed-off architecture, regulatory requirements matrix and first-release scope. |
| 2. Demo completion (Lovable track) | Finish agreed demo workflows with synthetic data only. | Investor demo accepted; no real bank data in the prototype. |
| 3. Production foundation | Repository, CI/CD, environments, identity with MFA and SSO, organisation and membership model, audit log, infrastructure-as-code. | Cross-tenant isolation tests pass; restore test passes. |
| 4. Core workflows on production stack | Vendor profiles and passports, marketplace, tenders and bids, contract repository and lifecycle, risk assessments, admin panel. | Acceptance tests pass on core flows; internal security review complete. |
| 5. Reporting and compliance features | Dashboards, exports, register-of-information export, DORA and GDPR report templates, notifications. | Output validated against the supervisory data format by a compliance reviewer. |
| 6. Pilot readiness | External penetration test, backup and recovery test, incident-response drill, DPIA, standard DORA contract annex, subprocessor list. | No open critical or high findings; legal sign-off on contract pack. |
| 7. Controlled pilot | One or two friendly institutions, real data under contract. | Pilot exit review, customer feedback and compliance evidence pack. |
| 8. AI and integrations | Document extraction, clause analysis, human review, SSO and API integrations. | Measured accuracy targets met; AI Act classification and DPIA recorded. |
| 9. Certification and scale | ISO 27001 programme, SOC 2 if required, performance and resilience testing, premium isolation tier. | Certification audit scheduled; load test at target volume passed. |
Migration approach. Data model and workflows move from the prototype by script. The Lovable code is retired phase by phase as each production module passes its gate, so there is never a big-bang cut-over.
12. Testing, delivery, commercial structure and final recommendation
Testing. Beyond screen checks, we test authentication and approval flows, role and administrator permissions, organisation-level data isolation, document access and upload validation, tender deadlines and bid handling, audit-log completeness, backup restoration, accessibility, mobile and desktop use, and AI output quality. A living register records known limitations and test results so stakeholders can separate finished functions from sample-data screens.
Delivery and handover. Source code and repository access, schema and migration scripts, environment and deployment documentation, rollback instructions, administrator and user guides, test results, a third-party and subprocessor inventory, security and resilience documentation for customer due diligence, and a roadmap. All accounts, cloud projects and subscriptions are created under the client's ownership.
Commercial structure
The price is set per milestone after the technical audit, not as one undifferentiated figure.
| Milestone | Scope |
|---|---|
| 1 | Technical audit, architecture and regulatory requirements matrix |
| 2 | Demo completion on the prototype with synthetic data |
| 3 | Production foundation: tenancy, identity, audit log, CI/CD, environments |
| 4 | Core workflows on the production stack |
| 5 | Reporting, exports and compliance templates |
| 6 | Pilot readiness: security testing, recovery tests, contract pack |
| 7 | AI features and integrations |
| 8 | Certification support and scale testing |
Hosting, database and identity subscriptions, AI usage, external penetration tests, certification audits, legal review and ongoing support are quoted separately from development.
Main risks
| Risk | Mitigation |
|---|---|
| Rebuild cost and delay | Reuse the prototype's data model and design; migrate module by module. |
| Regulatory change (AI Act, GDPR amendments, NIS2 transposition) | Quarterly regulatory review; decisions recorded in the requirements matrix. |
| Cross-tenant data leak | API-level authorisation, row-level security, isolation tests in CI, external penetration test. |
| Customer demands ISO 27001 or SOC 2 before pilot | Start the certification programme in phase 6 and offer a security whitepaper meanwhile. |
| AI cost or quality | Per-tenant limits, labelled test set, human review. |
Final recommendation. Keep Lovable for the investor demo and nothing else. Approve the technical audit and regulatory requirements matrix now, build the production platform on managed EU cloud with organisation-level access from the start, and complete the security and resilience evidence pack before the first real bank sees confidential data. Neither Lovable nor custom cloud infrastructure alone establishes regulatory compliance; the controls, contracts and operating processes do.
Next step. Approve the audit and confirm first-release priorities. We then deliver the detailed plan with milestone estimates, infrastructure costs and acceptance criteria.
Sources (as of 14 October 2026)
- DORA Register of Information guide, SureCloud
- DORA third-party risk deep dive, Sedric
- DORA critical ICT third-party providers, SureCloud
- DORA register of information limited update 2026, FSMA
- EU AI Act Omnibus agreement, Gibson Dunn
- EU AI Act 2026 changes for deployers, Process Excellence Network
- CVE-2025-48757 record
- Lovable RLS exposure analysis, Superblocks
The GDPR, EBA outsourcing guidelines, NIS2, Data Act and Cyber Resilience Act entries come from general knowledge of the legislation, not from the pages above. Counsel should verify them.