Find unusual patterns and emerging risk.
Investigate linked accounts, unusual activity, repeated applications, and signals that need a deeper review.
ClearLend · Build series landing page
Meet ClearLend: a simple idea for lending money online.
ClearLend is a fictional online lending marketplace. It gives lenders a place to create loan products and gives borrowers a clear way to find, request and manage borrowing.
This landing page explains the product in plain English and gives you a clear route into the next two phases, where we define the business model and then start making technical architecture and code decisions with C#, ASP.NET Core, Angular and a reliable database.
A learning project · Fictional people · Simulated money · No real financial service
07 / Lender operations
A lender can manage the whole lending side from one dashboard.
This is the lender view of ClearLend: create products, decide when they are available, review requests and keep track of money that has been lent and repaid.
The lender first completes registration and vetting. Once approved, ClearLend records a lending limit: the amount the lender is currently allowed to make available through the marketplace.
From the lender dashboard they can create a product, set its amount, term, interest rate and eligibility rules, then save it as a draft before publishing it. Products can later be edited, paused or archived, with the change recorded in the history.
The same dashboard shows borrower applications, active loans, lending commitments, repayments received, remaining balances and upcoming payments. This gives the lender a useful view of both the products they offer and the lending activity that follows.
The lender must also understand what is private and what is shared. They can see the terms of their own products and the applications made visible to them, but they should not see another lender’s private records or internal compliance notes. A lender can make a product public without making every piece of their business profile public. These choices shape the permissions model and the read models used by the dashboards.
Product changes need careful handling. Changing a rate or term on a draft is simple; changing a published product may affect new applications, existing offers, or only future requests. ClearLend should make that effect explicit. The lender should see a preview of the change, a reason, an effective time, and whether a review is required. Pausing a product should stop the intended activity while preserving the history of existing applications.
The lender also needs useful notifications: a product is approved or returned, an application needs attention, a commitment is recorded, a payment is received, a settlement is uncertain, or a balance has changed. These events should be linked to the correct product, application, loan, or payment so a lender can investigate without searching across unrelated screens.
The lender role also gives us a useful lesson about versions and projections. A portfolio dashboard should be fast to read, but it must be built from authoritative commitments, settlements, repayments, and adjustments. A product list can be a read model, while the domain still owns whether a product may be published or paused. When the series reaches implementation, we can show how commands change the domain and how queries serve a dashboard without letting the dashboard bypass the rules.
That makes the lender a strong teaching example for commands and queries. Creating a product is a command with validation and ownership; listing products is a query shaped for the dashboard; publishing is a controlled state change; and portfolio figures come from recorded financial events. The role gives readers a practical reason for the architecture instead of an abstract layer diagram.
08 / Borrower operations
A borrower can follow every step from their own dashboard.
The borrower view makes the process understandable: what information is missing, what was decided, what is due next and where to get help.
The borrower starts by registering and completing a profile. ClearLend shows the information needed for vetting and makes the current status visible instead of leaving the borrower guessing.
Once a credit limit is available, the borrower can browse loan products and submit an application. The application can be in progress, under review, approved or denied. If it is approved, the borrower can see the exact offer and accept or decline it. If it is denied, the system should show a clear status and an appropriate explanation.
After accepting an offer, the dashboard becomes the place to track the loan, see the next payment due, review past payments, check the remaining balance, read notifications and contact support.
The borrower also needs control over their own information. They should know which data is required, which data is optional, which data is shared with a lender, and how to correct a mistake. The system should not expose internal risk notes, another borrower’s information, or a lender’s private portfolio. This creates a clear authorisation boundary for the API and a clear explanation for the interface.
Notifications are part of the borrower journey, not an afterthought. A notification can tell the borrower that evidence was rejected, a reviewer asked a question, an offer is ready, a payment is due, a payment failed, or a support case changed. Each notification should link to the relevant record and remain visible in a notification history. Later we can decide which notifications are email, in-app, or both.
These needs give us useful development slices: registration and profile, evidence submission, credit-limit review, product search, application submission, offer acceptance, payment history, and support messaging. Each slice can have its own endpoint, domain rules, authorisation checks, tests, and user-facing evidence.
From a product-planning point of view, the borrower gives us the clearest example of why the roles must be explicit. A borrower can be waiting for a reviewer, a lender, a payment provider, or support, and each wait has a different meaning. The interface should show the owner, the expected next action, and the safe way to ask a question. The API should enforce that a borrower can withdraw a draft, accept an offer only while it is valid, and see a payment only when the payment is linked to their loan. Those rules become acceptance criteria, automated tests, and security checks in later phases.
That detail matters for planning. We can start with a borrower who creates a draft and receives a validation response, then add vetting, product search, submission, review, offer, and repayment as separate slices. Each slice gives readers a complete example they can run and extend while the role definition keeps the product story consistent.
09 / Support operations
Support staff give borrowers and lenders a clear route to help.
Support is more than answering messages. It is a managed case journey that protects privacy, keeps promises visible and gets the right people involved when a case needs specialist attention.
Messages from borrowers and lenders arrive in one support queue. The support person verifies the account and links the conversation to the right application or loan before discussing private details.
Each case has a category, priority and response timer. Support can send a public reply or request information from the customer, while keeping private internal notes for the team. Those two types of communication must stay clearly separate.
Some cases can be resolved by support. Others need to be escalated to CRM, operations or compliance. Complaints, repeated problems and cases that may affect a customer outcome should remain visible until someone owns the next action and records the result.
The dashboard should show open and urgent cases, cases awaiting a customer, response deadlines, escalations, complaints and cases resolved today. That helps the team manage work fairly instead of relying on an unmanaged inbox.
Support staff must work within carefully designed permissions. They need enough context to answer a question, but they should not be able to change a credit decision, edit a payment balance, or view evidence without a legitimate case. Sensitive actions can require a reason, an approval, or a handoff to CRM, finance, compliance, or servicing. The application should make the safe path easier than an informal workaround.
A case timeline should show the original message, public replies, internal notes, status changes, assignments, escalations, attachments, and outcome. Search should work by case, customer, application, loan, product, and provider reference, with access checks applied to every result. A resolved case should explain what was done and whether follow-up is required rather than simply disappearing from the queue.
These responsibilities make support a useful first vertical slice. We can demonstrate creating a case, assigning it, adding a public reply and internal note, changing priority, escalating it, and recording an outcome. That small feature exposes authentication, authorisation, state transitions, notifications, audit events, and a practical Angular dashboard.
Support is also where human language meets technical state. The customer may say, "my money has not arrived," while the system contains a pending settlement, an unknown provider response, or a balance awaiting reconciliation. Support needs a clear translation between those views. The case should preserve the customer words, the internal diagnosis, the linked records, and the final outcome. This keeps future agents from asking the same questions again and gives the business evidence about where the product is confusing people.
That is also useful for product quality. A support case is a small but realistic workflow with a person, a status, an owner, a due time, messages, and an outcome. It can demonstrate validation, concurrency, notification delivery, search, authorisation, audit events, and the difference between a customer-facing response and an internal technical note.
10 / CRM and credit review
The review manager turns evidence into a reasoned decision.
This role reviews both sides of the marketplace. They are responsible for making sure the right information is available, the rules are applied consistently and every decision can be explained later.
The manager works from review queues for borrowers, lenders and applications. They verify identity and documents, check the information needed for a creditworthiness review, and make sure the lender and product rules are clear before a decision is made.
For a borrower, the review may confirm a credit limit or ask for more information. For a lender, it may confirm the profile, lending capacity and products they want to publish. An application can then be approved or declined with a recorded reason, or escalated when the case does not fit the normal path.
The dashboard also needs to show missing evidence, exceptions, decision turnaround, approval and decline reasons, and outcome monitoring. This helps the team find repeated problems and check whether the product is producing fair, understandable results over time.
ClearLend is a fictional learning project, so this page is not legal or regulatory advice. It demonstrates the engineering shape of a review function: evidence, rules, human decisions, reasons, permissions and an audit trail.
The review manager also needs a way to pause a decision without losing momentum. A case can be waiting for evidence, waiting for an external check, waiting for a second reviewer, or escalated for a policy exception. Each waiting state needs an owner and a due date. Otherwise the organisation may confuse an unfinished case with a decision that was deliberately deferred.
Review evidence should be linked to the requirement it satisfies. A document can support identity, address, ownership, income, capacity, or another policy question. The manager should be able to mark evidence as accepted, rejected, expired, or superseded and record why. A later reviewer should be able to understand the case without relying on the memory of the first reviewer.
The role also needs controlled reporting. It can compare turnaround by product, reason codes by decision, evidence rejection rates, and escalations by category. Those reports are not intended to replace human judgement; they help the business find unclear rules, inconsistent training, or products that are creating avoidable friction.
The review manager work should be designed for consistency without pretending that every case is identical. The system can enforce required evidence, permitted states, reason codes, and approval permissions, while the reviewer still records a judgement that may need explanation. A decision should be reversible only through a new decision or appeal record, never by editing the original row. That approach gives later development a strong example of domain invariants, immutable history, and a testable policy boundary.
The role is also a natural place to teach reviewable software. We can show a policy service returning a result, a human reviewer confirming or changing it with a reason, and an audit record capturing the difference. The system supports judgement without hiding the rule, and it supports automation without pretending that automation removes responsibility.
11 / Business owner operations
The application owner keeps the whole marketplace under control.
This is the senior business view of ClearLend. The owner does not process every case personally; they make sure the right people, rules, reports and controls are in place.
The owner monitors the health of the marketplace: active borrowers, active lenders, published products, loans in progress, lending activity, repayments, exceptions and system health.
They manage roles and permissions, approve or pause products, pause an application when something needs investigation, assign ownership, publish a platform notice and make sure changes are recorded in the audit history.
The dashboard also connects business performance with responsibility. Support and complaint trends, risk and compliance alerts, incidents, response times and customer outcomes help the owner see where the service is working and where it needs attention.
This role makes ClearLend more than a set of borrower and lender screens. It gives the application an accountable owner who can make informed decisions, protect the operating boundaries and improve the service over time.
The owner needs a reliable view of operating health rather than a single headline number. They can compare application volumes with turnaround, support demand, complaints, payment exceptions, and system incidents. A product that attracts many applications but creates repeated evidence failures may need a rule or explanation changed. A healthy marketplace is one where people can make progress and the organisation can explain the decisions.
Administrative actions need safeguards. Changing a role, pausing a product, publishing a notice, or reopening an incident should require the right permission and produce an audit event. High-impact actions can require two people or a review reason. The owner should be able to see active incidents, who owns them, the affected users, the temporary control, and the conditions for returning to normal operation.
That makes the application owner an important architectural boundary. Platform administration, business configuration, reporting, feature controls, and operational evidence belong together but should not be mixed into borrower or lender code. Later phases can demonstrate how an ASP.NET Core application keeps these boundaries explicit.
The owner also needs a safe way to compare change over time. A new product, policy, notification rule, or payment process can change customer outcomes even when the code appears healthy. The dashboard should allow the owner to see when a change was introduced, which users it affects, and whether support contacts, complaints, decisions, or payment exceptions moved afterwards. This is the bridge between product management and engineering observability.
For the website audience, this role shows that senior development includes operational thinking. A good application is not finished when the screen works; it is finished when the owner can understand its health, control a problem, assign responsibility, and explain the evidence behind an important change.
It also gives us a clear place to demonstrate configuration without scattering settings through the codebase: business rules, notification policies, role permissions, product controls, and incident actions can have owners, versions, and audit records.
12 / Compliance team
Compliance turns records and decisions into evidence people can inspect.
The compliance team checks that ClearLend is being operated as designed. It has enough information to review a case, understand why a decision was made, see who was responsible and produce a structured inspection pack.
The team receives compliance cases from onboarding, lending, support, payments, and monitoring alerts. They collect identity, business, ownership, transaction, and communication evidence, then check that the information is complete, current, and linked to the right person or organisation.
Every decision should show the policy version used, the evidence considered, the reviewer, the date, the reason, and any second approval required. A case can be approved, restricted, returned for more information, or escalated without hiding the original record.
The dashboard tracks open reviews, missing or expired evidence, high-risk cases, escalations, decision reasons, retention status, audit timelines, and inspection packs. It also helps the team find repeated control failures instead of treating every case as a one-off.
This makes ClearLend audit-ready by design. It does not promise automatic regulatory approval; the organisation still needs suitable policies, people, oversight, and legal advice.
Compliance receives cases from onboarding, lending, support, payments, and monitoring alerts. The team collects identity, business, ownership, transaction, and communication evidence, then checks that it is complete, current, and linked to the correct person, lender, product, application, or payment.
A decision should record the policy version used, the evidence considered, the reviewer, the date, the reason, and any second approval. A case can be approved, restricted, returned for more information, or escalated without deleting the original record. If a document is replaced, the history should show the old document’s status and the reason for the replacement.
The compliance dashboard shows open reviews, evidence awaiting, high-risk cases, expired documents, escalations, decision reasons, retention status, audit timelines, and inspection packs. An inspection pack can bring together the case file, evidence bundle, communications, decision log, policy version, and monitoring report. The team should be able to export it for an authorised review without granting an inspector the ability to change operational data.
Compliance also looks across cases. It can find repeated control failures, decisions that take unusually long, evidence that is often rejected, products linked to complaints, or teams that need clearer guidance. This turns compliance from a final inspection activity into an ongoing feedback loop.
ClearLend is a fictional learning project and cannot promise regulatory approval. The engineering goal is to make the application audit-ready by design: evidence, traceability, retention, access control, decision reasons, and accountable ownership are visible from the beginning.
The compliance team also needs controlled access to personal information. A reviewer should see only what is necessary for the case, an export should have a reason and an owner, and an inspection link should expire or be revoked. Retention is not simply keeping everything forever; the system needs a policy for how long records are held, when they are reviewed, and what can be safely deleted. These controls make privacy, audit, and security part of the same design conversation.
13 / Finance and settlement
Finance makes sure the records agree with what actually happened to money.
The finance and settlement team handles the careful work between an accepted agreement, a payment provider, a lender balance, and a borrower balance.
When an offer is accepted, ClearLend records the commitment and creates the settlement work. The finance team can see whether a settlement is pending, processing, completed, failed, reversed, or still unknown.
They compare the application’s internal records with payment-provider reports, investigate differences, allocate a payment to the correct loan, update lender and borrower balances, and record fees or refunds. A payment that has no reliable final result is sent to a review queue rather than being silently treated as successful.
The finance dashboard shows pending settlements, completed payments, failures, unknown outcomes, reconciliation differences, refunds, fees, lender balances, borrower balances, and exportable reports. This gives the business a controlled way to close the gap between a system record and a real-world payment event.
When an offer is accepted, ClearLend records the commitment and creates settlement work. Finance needs to see whether a settlement is pending, processing, completed, failed, reversed, or still unknown. The application must not treat a request to a payment provider as proof that money moved.
The team compares internal records with provider reports and bank or ledger information. They investigate differences, allocate a payment to the correct loan, update lender and borrower balances, and record fees or refunds. If the provider gives an unknown outcome, finance opens a review case and prevents the same transaction from being submitted repeatedly without an idempotency decision.
The dashboard shows pending settlements, completed payments, failures, unknown outcomes, reconciliation differences, refunds, fees, lender balances, borrower balances, and exportable reports. Each record should link back to the agreement, commitment, payment attempt, provider reference, and reconciliation result. That makes a finance report explainable rather than a number with no source.
Finance also needs controlled corrections. A correction should create a new adjustment or reversal record instead of overwriting the original payment. A refund should have a reason, an approver, a reference, and an effect on the correct balances. A failed payment should be visible to servicing and support so that the borrower and lender receive consistent information.
This role drives money-state modelling, idempotency, provider boundaries, transaction handling, reconciliation jobs, balance calculations, exception queues, reporting, and integration tests. It is a strong future vertical slice because it demonstrates how a senior engineer handles uncertain external systems.
Finance also protects the difference between an operational estimate and a confirmed balance. A dashboard may show a payment as expected, pending, or projected, but a confirmed balance should only change after the correct event has been recorded. Reconciliation jobs need retries, duplicate protection, clear failure states, and a way for a person to approve a correction. These are exactly the situations where a small C# example can teach more than a large diagram.
14 / Loan servicing and collections
Servicing keeps the loan understandable after it has been funded.
The servicing team manages schedules, reminders, payments, missed payments, borrower conversations, arrangements, lender updates, and loan closure.
After funding, the team creates the repayment schedule and sends useful reminders. Each payment is received, allocated, reconciled, and reflected in the borrower’s remaining balance and the lender’s records.
If a payment is missed or fails, the case enters a managed process. Staff can contact the borrower, understand the situation, record messages, agree an appropriate arrangement where the business allows it, and escalate a dispute or hardship case to the right team.
The servicing dashboard shows active loans, payments due, payments received, missed payments, arrangements, borrower messages, remaining balances, lender updates, and loans closed. It keeps follow-up work visible and gives borrowers a clear way to understand what they need to do next.
After funding, servicing creates the repayment schedule and sends useful reminders. Each payment is received, allocated, reconciled, and reflected in the borrower’s remaining balance and the lender’s records. The schedule should show what is due, when it is due, what has been received, and what remains unresolved.
If a payment is missed or fails, the case enters a managed process. Staff can contact the borrower, understand the situation, record messages, agree an arrangement where the business allows it, and escalate a dispute or hardship case to the right team. The process should be respectful and explainable; it should not turn a missed payment into a hidden or automatic punishment.
The servicing dashboard shows active loans, payments due, payments received, missed payments, arrangements, borrower messages, remaining balances, lender updates, and loans closed. Servicing staff need to see the complete history before contacting someone, including previous promises, failed attempts, support cases, and approved changes to the schedule.
Lenders need accurate updates when a payment is received, delayed, reversed, or placed under review. Borrowers need a clear statement of the next action and a safe way to ask for help. The same event can therefore create different notifications for different roles, with permissions controlling what each person can see.
This role drives scheduled work, reminders, payment allocation, arrears states, arrangements, communications, balance updates, closure rules, and background processing. It gives later phases a realistic way to demonstrate reliable jobs, retries, idempotency, audit history, and customer-centred exception handling.
Servicing needs clear ownership when a loan changes state. A reminder may be automated, but a missed payment that becomes a dispute, arrangement, or complaint needs a person and a due date. The history should show the schedule before and after an approved change, the message sent to the borrower, the lender update, and the reason for the change. That gives every later team enough context to act without making the borrower repeat the story.
Servicing therefore becomes a later masterclass in dependable background work and humane exception handling, not merely a payment table.
15 / Possible later roles
More specialist roles can be added as the application grows.
These roles are useful extensions, but they do not need a dedicated visual yet.
Control access and personal-data operations.
Manage privileged access, access reviews, data exports, retention, deletion requests, and security incidents.
Read evidence without changing operations.
Use controlled, time-limited access to inspection packs, reports, decisions, and audit trails.
Why follow this project?
Follow the decisions, not just the finished screens.
ClearLend is a practical way to see how Afzal approaches a complicated business application from the first conversation to a reliable technical implementation. The money is simulated and the users are fictional, but the engineering work is real, deliberate and useful to anyone building serious software.
See the reason behind every feature.
We explain what borrowers, lenders and operations teams need before choosing endpoints, tables or frameworks. That keeps the software connected to a real business outcome.
Watch the architecture become code.
The series moves from business rules to C#, ASP.NET Core, persistence, security, testing, performance and production concerns. Readers get patterns they can adapt to their own systems.
See senior judgement in practice.
Afzal shows how to simplify a large problem, protect important decisions, explain trade-offs and deliver useful slices without pretending that a full financial platform appears overnight.