Low-code and no-code platforms let a non-specialist assemble a working automation by configuration rather than code, and that is a genuine capability, not a toy. For a FINMA-regulated institution the honest question is not whether low-code works, because it often does, but where its limits fall. In a controlled process those limits land on exactly the parts that decide whether an automation survives a review: the data it touches, the traceable record it leaves, and who owns it the day the platform changes its terms. Read the limits wrong and the fast, cheap option quietly becomes the exposure.
Start with where low-code genuinely fits, because the case for it is real. Light integrations between systems, simple internal automations, a prototype that proves a workflow is worth building before anyone commits to a full build: for a bounded task with non-sensitive data and a person still checking the output, a low-code assembly is faster to stand up and cheaper to change than custom code, and reaching for a full engineering build there is over-engineering. The test for the sweet spot is plain: low volume, simple logic, forgiving data, and a human in the loop. Inside that box, low-code is not a compromise. It is the right tool.
The first limit is volume and logic. As the number of cases rises and the logic grows branches (the exceptions a person used to handle by judgment, the reconciliation that does not reconcile), a flow that was elegant at ten cases turns brittle at ten thousand. The platform's visual logic, a strength for a simple path, becomes a liability no one can fully read or test once the real complexity of a regulated reporting process arrives. What saved time at the prototype stage starts costing it, because every new exception is another box bolted onto a diagram that was never designed to carry the load.
The second limit is regulated data and auditability, and it is the one that bites hardest in finance. A low-code platform typically processes your data on infrastructure you do not control, under terms you did not write, with a lineage that is hard to reconstruct months later when an internal reviewer asks how a figure was produced. Naming where the data sits, who touched it, and how a decision can be traced back is not an add-on in a FINMA-regulated process; it is the requirement. It is also precisely what a configuration-first platform, built to hide its plumbing in the name of ease, is least able to answer.
Then there is the cost that does not show up in the demo: ownership. The surface appeal of low-code is speed and an apparently low price, but the real bill arrives later and in three parts. The automation runs only as long as you keep paying the platform's standing subscription; the logic lives inside the vendor's environment in a form you cannot export cleanly; and the day you outgrow it, or the vendor reprices or retires a feature, you rebuild from scratch rather than migrate. A low-code flow is rented capability. Renting what is genuinely disposable is sensible. Renting what has quietly become load-bearing is the expensive mistake.
So the decision is not low-code against custom in the abstract, but a reading of the workflow in front of you. Rent, with low-code, what is low in volume, low in sensitivity, and genuinely temporary, and do not pay for custom engineering there. Own, with a proper build, what is high in volume, heavy in logic, touches regulated data, or has to answer a reviewer and keep running for years, because those are the automations where the rented limits become your risk. The failure is letting the initial speed of a low-code build decide the architecture of a process that was always going to be load-bearing, and discovering the gap at the first audit request.
That reading is the first thing an assessment settles, before any tool is chosen: which workflows are disposable and which are load-bearing, and therefore what is worth owning. It is how reporting across 39+ funds at IST Investmentstiftung was built, as an owned pipeline the institution runs and audits itself rather than a rented flow, one measurable workflow at a time. If you are weighing a low-code shortcut against an owned build and want to decide it on the shape of the work rather than the speed of the demo, an AI Audit is where it starts: it maps the workflow, the data, and the real scope, so the build-approach question answers itself. It is the same discipline that runs through everything we build.