Suppose a borrower and a private lender sign a three-month extension. The lender’s new servicing app stores the agreement and displays the revised maturity date. Everything looks settled until the borrower requests a payoff. The calculation still uses the original maturity date and adds default interest that the extension should have prevented. A staff member catches the mistake and asks an AI coding assistant to fix it. The next payoff comes out correctly. The lender still has to find the earlier statements affected by the error and decide how to correct them. If the app overwrote its previous calculations, someone now has to reconstruct the history.
The demo ends before the obligation does. That gap is where I would look before accepting a claim that AI has made a lending operation cheap to build. Generating the application may cost less. Understanding its decisions and repairing the consequences still require people who know what they are doing.
By “vibe coding,” I mean prompting AI to generate an application and requesting changes until it appears to work, without understanding or independently reviewing the code. An experienced developer can use AI without working this way. My objection is to putting an unreviewed prototype in charge of live financial records because its first demonstration looked convincing.
The extension example exposes how much judgment sits behind an ordinary screen. Someone must establish when the amendment became effective and what it changed. The approved terms have to reach the calculation engine. A correction needs enough history to explain the old balance, including who authorized the change. Another amendment may introduce terms the first version never anticipated. The person who built the app may finish long before the loan pays off. Someone else inherits the task of explaining it.
The portal inherits the fund’s legal decisions
Investor onboarding has the same timing problem. A portal can collect a subscription agreement and display “approved” within minutes. The fund may have to defend the basis for admitting that investor years later. A lender investing its own capital and a manager raising money for a pooled fund need different legal analyses. For a fund, the securities offering and the vehicle’s investment company status raise separate questions. The manager’s investment adviser obligations require their own analysis. An LLC formation document settles none of them.
Consider a portal with one accredited investor checkbox. In a Rule 506(c) offering, all purchasers must be accredited, and the issuer must take reasonable steps to verify that status. Checking a box does not, by itself, establish that the issuer met the verification obligation. Rule 506(b) generally prohibits general solicitation and permits limited participation by sophisticated non-accredited investors, subject to additional requirements. A copied onboarding template can apply the wrong assumptions to every subscription it processes.
The fund’s investment company exclusion adds another distinction. Section 3(c)(1) generally limits a fund to 100 beneficial owners; Section 3(c)(7) generally requires qualified purchasers. Accredited investors and qualified purchasers meet different legal tests. A field labeled “qualified” hides information the person reviewing the subscription needs to see.
An investor may participate in more than one fund. Reusing their contact information is convenient. Reusing an approval without checking the second fund’s requirements carries a legal conclusion into another transaction. A defensible record connects the investor’s eligibility evidence to the particular fund and offering that the reviewer approved.
Errors can also travel in the other direction, out of servicing and into investor communications. Federal antifraud provisions apply to exempt offerings. An automated update that materially misstates portfolio performance because it pulled an incorrect balance can create exposure for the firm. A polished report makes an unsupported number easier to circulate. It gives the recipient no reason to suspect that the underlying calculation needs attention.
An AML feature needs an applicable rule
The instruction to “add AML compliance” gives a developer little to work with until the lender determines which anti-money laundering duties apply to its business. Covered nonbank residential mortgage lenders and originators already have AML program and suspicious activity reporting requirements. The definition of a residential mortgage loan includes loans secured by specified residential property with one to four units. The regulatory definition and its exclusions matter more than a business purpose label. That label alone cannot settle whether a lender falls within the rule.
The investment adviser rule follows a different timetable. FinCEN postponed its effective date to January 1, 2028. Its coverage concerns specified SEC-registered advisers and exempt reporting advisers, subject to exclusions. As of October 2026, describing it as a current AML mandate for every private lending fund would give the reader the wrong answer. The postponement also leaves existing mortgage company obligations in place.
For a covered mortgage business, the AML program requirements include senior management approval and a designated compliance officer. They also require training and independent testing. A screening feature can support that program. It cannot supply the employee’s training or explain why a reviewer dismissed an alert.
That last point creates a management problem. If the business measures staff only on how quickly accounts clear onboarding, a warning becomes something that delays the work. Software that automatically dismisses warnings may make the queue look better while suppressing matters that deserved review. The application needs to preserve the basis for a disposition, and management needs to allow time for someone to reach it.
The SEC can investigate and seek civil penalties for securities law violations. FinCEN can impose civil money penalties for violations of applicable Bank Secrecy Act requirements. Those consequences depend on the conduct and the duties that apply. Using AI is not itself the violation. A system that produces misleading statements or fails to support required reporting can contribute to one. Even without an enforcement action, the lender pays for finding the affected records and correcting earlier work. The cost estimate for the app needs to account for that possibility.
Every new connection creates another place to check
An investor portal may hold tax documents alongside the evidence collected for investor verification. An investor needs access to their own files. A programming mistake that lets them retrieve another investor’s documents creates a problem even when every screen looks right.
An AI assistant can expose those records through another route. If an employee can ask it about a loan, the application has to restrict which records the assistant can retrieve. Giving it broad database access and asking it to respect confidentiality leaves access control to an instruction the software should enforce elsewhere.
Regulation S-P imposes safeguarding and incident response duties on covered institutions, including SEC-registered investment advisers. Coverage does not extend to every private lender. Other privacy laws and contractual duties may apply. The firm still needs to understand what information each provider receives and retains.
These details belong in the build cost. An engineer’s access test may reveal that a user can bypass a screen and request someone else’s file directly. A restoration test may expose a backup that cannot recover the records the business needs. Buying commercial software changes who built the system; the lender still needs evidence that the system fits its work.
I would also be cautious about a budget that ends at launch. A new loan product can invalidate a calculation that worked last month. An AI-generated fix can disturb another part of the app. Maintenance includes the time to understand those changes and test them before they affect live accounts.
Make the next decision with evidence
If you run a lending business with an unreviewed prototype, my proposed first step is a 48-hour decision you own personally: stop using successful demonstrations as approval for live use. Put your name on that decision. Keep the existing process authoritative while the prototype runs a controlled comparison with synthetic data. Choose one person to own that comparison and record their name.
Within the following 24 hours, that person can take a synthetic extension like the opening example through the app, with a servicing specialist calculating the correct payoff independently. The first result is a saved comparison that shows the expected balance and the app’s balance, with the amendment history available for inspection. A disagreement becomes a specific defect to investigate. A match establishes evidence about that case alone.
That owner also records any unresolved question about the applicable legal requirements, names the individual counsel or engineer who will examine it, and sets a review date before any production decision. The exercise is done when the comparison and those assignments exist. It does not certify the application for production.
The next release decision requires a scope and testing plan that address the business the app will actually handle. In the same record, the exercise owner names the person responsible for maintenance after the builder leaves and identifies who will fund that work. A lender can choose to own its software. It then has to keep paying someone to understand it for as long as the business relies on its records.
U.S. federal regulatory discussion checked October 9, 2026. State law and transaction-specific requirements need separate review.
