Solutions · Financial services
A financial services application is judged by what happens at its edges: what is written in the log, what happens when the client asks for their data back, what is seen in the pre-contractual information, and what happens when a scheduled task does not run. We build the mechanics; the credit policy remains yours.
Already builtO platformă de creditare în producție, verificabilă din exterior azi: partea publică e o aplicație compilată static cu 50 de ecrane, între care patru calculatoare — credit, eligibilitate, refinanțare, grafic de plăți — pagini pe tip de credit, informare precontractuală și o rută prin care clientul își cere datele personale; partea de business e un backend modular în TypeScript cu 16 module și 18 tabele în schema de date, între care contract, plată, jurnal de audit, cerere privind datele personale, document încărcat, instantaneu zilnic de indicatori și rulare de sarcină programată. Harta de site de pe producție listează 227 de adrese, iar rutele românești și cele rusești răspund amândouă — verificate de mine pe 06.09.2026. Rezerva pe care o spunem: dovada e din cod și din răspunsurile publice, nu din comportamentul intern al serverului — nu am verificat pe ce versiune rulează producția și nici că toate cele 16 module sunt active pe live.
A lending company does not need a website. It needs a complete chain: the application comes in online, passes through a decision flow, produces a contract, generates a payment schedule and leaves a trace in audit. Every missing link in the chain turns into a person copying data from one place to another, and in financial services every manual copy is also a compliance problem, not just a time problem.
The structure we build reflects this directly in the data. In the platform we cite, the schema has 18 tables, and the list says more than any architecture description: application, contract, payment, one-time code, session, appeal request, notification template, notification log, daily indicator snapshot, scheduled task run, article, address redirect, visibility setting, internal note, audit log, uploaded document, personal data request. The backend is split into 16 modules, including one dedicated exclusively to data subject rights.
The public side is not decoration: four calculators — credit, eligibility, refinancing and payment schedule — plus separate pages by loan type and the pre-contractual information. In consumer lending, pre-contractual information is not a page for appearance: it is the obligation to show the terms before the person commits. We treat it as a product requirement, not as legal text pasted at the end. Romanian routes remain without a prefix, while Russian ones run on a separate segment, with canonical labels and alternatives generated from the active route language.
And the limit that must be stated before the contract: the decision flow on applications — rules, thresholds, approval — is yours. We build the mechanics through which the application moves, is documented and becomes a contract. We do not write the credit policy and we do not take responsibility for assessing an applicant; these are decisions with legal consequences that belong to the authorised institution.
What it covers
The application comes in online and lives as its own entity, with visible status and a tracking screen for the client. Uploaded documents have their own table, the contract has its own table, payment has its own. The difference from a form that sends an email is that, three months later, the question “what happened to the application from 12 March” can be answered from the data.
The contract and the schedule are not assembled manually in a separate document: they come from the data of the approved application. It is the only variant in which the number in the contract and the number in the schedule cannot differ, and the client who calls with the document in hand is talking about the same thing as the operator looking into the system.
Credit, eligibility, refinancing and payment schedule — separate public screens, without authentication. In consumer lending, the calculator is the first real interaction: the person wants to see the instalment before speaking to someone. And refinancing is a different calculator from credit, not the same one with different labels.
Own page, not a paragraph in the footer. The reason is practical: if the information is not on the route the person follows before signing, it does not do its job for them or for the institution. The text is yours and your lawyers’; we build the place, the moment and the traceability.
There is a public page through which the client requests their personal data, a dedicated backend module and an administration screen for the received requests, plus a table in which they live. The practical consequence: the legal response deadline can be met without anyone opening the database manually — and it can be shown, a year later, that it was met.
The audit log is its own table, distinct from operators’ internal notes. The separation matters in an audit: one is the technical record of what happened, the other is what a colleague wrote about a file. Mixed together, the first becomes unreadable and the second becomes a document.
There is a table for scheduled task runs and one for daily metric snapshots. In a financial platform, a task that has not run for three nights in a row is a more serious problem than a page going down: it is not visible from the outside, but it changes the numbers. That is why the run is recorded, not assumed.
Romanian routes remain without a prefix, Russian ones go on a separate segment, with canonical and alternative labels generated from the language of the active route. The production sitemap contains 227 addresses. For a lending company in the Republic of Moldova, the Russian side is not a courtesy translation — it is half of applicants.
Pre-publish checks, database migrations run with a separate command in production, secrets generation, backup and database restore — all as scripts in the repository, not as steps in a document. In a system that holds contracts and payments, “restore” must be a command you have tried, not an intention.
Traseul
What it means for a request to be submitted, a request to be approved, a payment to be received; what happens to a request that has not been answered; what closes when an external service does not respond. We deliver the vocabulary and invariants document, because in a financial platform a term used in two senses later becomes two different figures in two reports.
The audit log and document record are not added at the end; they are part of the first working version. We deliver the full flow from request to contract, with its trace, on test data — not screens that look good over an empty database.
The public screens, calculators, pages by loan type and pre-contractual information, with Romanian addresses without a prefix and Russian ones on a separate segment, with correct canonical labels. We deliver the sitemap generated from data and the check that both versions respond.
Pre-publish check, production migrations with a separate command, secrets generation, backup and restore — tested, not just written. We hand over the repository, the deployment document and access. Database restore is demonstrated at handover, once, in front of you.
The data
The rules differ from one industry to another. These are the ones that apply in financial services.
A case
The situation
The initial requirement in a lending project almost always sounds the same: “a website with an application form”. The problem appears in the second month, when someone asks where the contract is, who changed the file and how we answer a request for access to personal data within the legal deadline.
What we built
We built the platform in two halves, in the same repository. The public part is a statically compiled application, with 50 screens: four calculators — credit, eligibility, refinancing, payment schedule — pages by loan type, pre-contractual information, application status tracking and a page through which the client requests their personal data. The business part is a modular backend in TypeScript, with 16 modules — including authentication, role rights, application flow, documents, payments, scheduled tasks and one dedicated to the data subject’s rights — over a schema with 18 tables: application, contract, payment, one-time code, session, uploaded document, audit log, personal data request, scheduled task run, daily metrics snapshot and the rest.
What came out
The chain is complete: the application enters, moves through, produces a contract and schedule, and every step leaves a trace. Personal data requests have their own route, with an admin screen, so the legal deadline can be met and demonstrated. The public part is verifiable from the outside: 227 addresses in the site map, with both language versions live.
What the case does not say
The proof comes from code and public responses, not from the server’s internal behaviour: we have not checked which version production runs on, nor that all 16 modules are active on live. The decision flow for applications — rules, thresholds, approval — belongs to the client; we built the mechanics, not the credit policy.
Questions
You. The rules, thresholds and approval are the policy of the authorised institution, not of the software provider. We build the mechanics through which the application moves, is documented, becomes a contract and payment schedule, and leaves a trace. A provider that takes on the lending decision sells something it has no right to sell.
There is a public page through which they request it, a dedicated backend module, an admin screen and a table in which the request lives. So it can be answered within the deadline and demonstrated later. What is not a technical decision: what can be deleted and what must be kept under financial legislation — that is established with your lawyers, before implementation.
From the approved application data, together with the payment schedule — both from the same source, so they cannot differ. What remains yours is the content of the contract and its terms. A contract composed manually in a separate document is the classic place where two different figures appear for the same loan.
Because in consumer lending, information has to be on the path the person takes before committing, not in a footer. We treat it as part of the product: the place, the timing and the traceability are ours, the text is your lawyers’ responsibility.
At least as many as correspond to different decisions. In the platform we cite, there are four — loan, eligibility, refinancing, payment schedule — because refinancing is not the same calculation as a new loan, and the schedule answers a different question than the instalment. One calculator with many fields is harder to use than four simple ones.
No, and that is a rule, not a preference: we build and test on test data. Access to real data, when necessary, is done with named people, for a set period and with a log trail. In a financial system, “I needed to look in production” is a sentence that must appear in a log, not in a discussion.
It can be seen, because runs are written to a dedicated table, alongside daily indicator snapshots. This matters precisely because a task that did not run produces no visible symptom from the outside — the site responds, the screens look fine, but the figures no longer move.
No volume figure, interest rate, number of applications or number of clients, even if it is shown publicly on their site — because it is their claim, not our measurement. What we can show is the structure: how many modules, what tables, what public screens, what is checked at publication. The same rule will apply to your work.
The public part can be checked now: the site map has 227 addresses, and the Romanian and Russian versions of a calculator both respond. The backend part is read from the code — modules and data schema — not from server behaviour: we have not checked which version production runs on, nor that all modules are active live, and we prefer to write that rather than leave the opposite impression.
Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.