Regulation as an Operating System

Most PropTech companies treat regulation as a ceiling. The companies that survive treat it as the floor.

The distinction sounds semantic. It is not. One orientation produces a product that fights its operating environment. The other produces a product that runs on top of it, and gains compounding advantages from every regulatory update that kills slower competitors.

After spending the last three years building financial technology for the Malaysian property market, a market with one of the most architecturally coherent regulatory stacks in Southeast Asia, I want to make this argument carefully. Not as a pitch. As a structural observation about why regulated markets reward a particular kind of thinking, and punish another kind consistently.

The Ceiling Mindset

The ceiling mindset is easy to recognise because it shows up in the first question founders ask when they enter a regulated space: What are we not allowed to do?

This is a compliance question. Compliance thinking produces compliance answers: a legal checklist, a list of prohibited activities, a mapping of risk boundaries. The product gets built around the gaps: the white spaces where regulation hasn't said no yet.

This works until it doesn't. The gaps close. The regulation updates. A new enforcement interpretation eliminates the business model, or a competitor who understood the regulatory architecture earlier builds network effects that make late entry structurally impossible.

I have watched three PropTech startups fold in Malaysia in the last 18 months for this reason. Not because the technology was bad. Because the product assumed that regulation was a fixed wall with permanent openings in predictable places.

What an Operating System Actually Is

An operating system is not a constraint. It is a substrate.

An OS defines the primitives: the stable abstractions that application developers can depend on. File handles. Network sockets. Process scheduling. These primitives are the load-bearing structure. If you build on them, you get reliability for free. If you try to circumvent them, you pay the cost of that circumvention every time the OS updates.

Malaysian property regulation works the same way. The stack has four main layers:

Layer 1, The Kernel: Valuers, Appraisers and Estate Agents Act 1981 (Act 118) Act 118 is the definitional layer. It specifies who is authorised to produce a professional valuation, what that valuation must contain, and what liability attaches to it. Every downstream tool, every data aggregator, every AI system that touches valuation output operates within the constraints of Act 118, whether it knows this or not.

Layer 2, The Enforcement Layer: LPPEH (Board of Valuers) LPPEH is the runtime enforcement. It licenses practitioners, runs disciplinary proceedings, and issues practice guidelines that interpret Act 118 for current market conditions. When LPPEH tightens CPD verification or changes the allowable methodology for a restricted asset class, this propagates through every tool a registered valuer uses.

Layer 3, The Data Layer: JPPH (Valuation and Property Services Department) JPPH maintains the transaction database: the authoritative record of property sales against which market valuations are benchmarked. Access to JPPH data is the data dependency that no Malaysian PropTech product can avoid. It is the canonical source. Build on it and your product inherits its authority. Build around it and your product is permanently in a legitimacy gap.

Layer 4, The Payment Layer: BNM (Bank Negara Malaysia) BNM governs the financial flows. For property transactions specifically, this covers disbursement of purchase consideration, stakeholder account management, and the disbursement schedule tied to construction milestones. BNM's payment framework is not a peripheral concern. It is the transaction architecture itself.

These four layers are not arbitrary constraints. They are the result of decades of market failures, enforcement learnings, and legislative refinement. They encode what it takes to make a RM500,000 transaction legible enough for two strangers to complete it safely.

The founding insight: If you build on this stack rather than against it, the regulation does not slow you down. It does your distribution for you.

What Building on the Stack Looks Like in Practice

The clearest example from our own portfolio is how we designed Valuer Copilot.

The initial instinct, the ceiling-mindset version of this product, would have been to build an AI that produces valuations. Fast, cheap, no licensed professional required. The product gets to market quickly. It also gets a regulatory citation within twelve months, because Act 118 is explicit: a professional valuation requires a registered valuer's signature and carries that valuer's professional liability.

We built the opposite. Valuer Copilot is a tool that licensed valuers use to do their work faster, with better data access, and with an auditable derivation chain that protects them in the event of a dispute. The registered valuer is not removed from the workflow. The tool makes the valuer more productive without removing the professional responsibility layer.

This is not a legal compromise. It is the product architecture that makes regulatory adoption possible. When LPPEH is evaluating whether to endorse a technology tool, the question is not "does this tool produce good output?" The question is "does this tool preserve the practitioner accountability structure that the Act was designed to protect?" A tool that answers yes to the second question gets a very different reception than one that doesn't.

The regulatory stack, in this framing, becomes distribution. LPPEH's practitioner network is our user base. JPPH data access is our data moat. BNM's disbursement framework is the integration requirement that every bank must comply with anyway, which means our compliance reduces integration cost, not adds to it.

This is the same logic I apply when scoping any 0→1 product sprint: the constraint is the opportunity. Find where the constraint creates a protected class of users, and build for them.

The Compounding Advantage

Here is the compounding effect that the ceiling mindset misses entirely.

Regulatory updates are pain for companies that treat regulation as a ceiling. Every update requires a response: a legal review, a product patch, potentially a business model revision. Regulatory cycles are unpredictable. The compliance cost is ongoing.

For companies built on the regulatory stack, updates are a different animal. When BNM tightened the disbursement requirements for progressive payment schedules in 2024, companies built on the payment architecture absorbed the update cleanly. Companies that had built informal payment tracking tools were either forced to rebuild or exit the segment.

When LPPEH updated the CPD audit trail requirements in 2023, tools that were already generating structured audit logs had nothing to do. Tools that were not generating structured logs had a choice: add the capability under pressure, or lose market standing.

Every regulatory update acts as a market filter. If your architecture is already aligned, you pass through. Competitors who cut corners face a restructuring cost at the same moment they need to compete with you.

The regulation does not tighten against you. It tightens against whoever is weakest in the market, and hands you their market share.

The Design Principle Extracted

This is not a principle unique to Malaysian PropTech. It applies in every regulated vertical: healthcare, financial services, legal technology, education, construction, food safety.

The founding question is not: What does regulation prevent us from building?

The founding question is: What does the regulatory stack make possible that would be impossible without it?

Valuer Copilot is only viable because Act 118 creates a class of licensed professionals with a workflow problem. Without Act 118, the market looks like any other information service, and the information service companies that have global scale will always outcompete a local tool.

PaymentXchange is only viable because BNM requires transactional parties to route property payments through specific structures. Without that requirement, the transaction is handled bilaterally and there is no platform layer available.

The regulation creates the market structure. The market structure creates the platform opportunity. The platform that understands the regulation deeply enough to inhabit that structure has a structural advantage that a fast-moving competitor cannot replicate without also replicating the regulatory understanding.

What This Means for Founders

If you are building in a regulated market, there are three things worth doing before your first line of code:

1. Map the regulatory stack, not the regulatory gaps. Read the Act. Read the enforcement agency's guidance. Read the data authority's access policies. Read the payment framework. Not to find what you can't do, but to understand what each layer makes possible that couldn't exist without it.

2. Identify the practitioners, not just the end users. In most regulated markets, there is a licensed professional class who already occupy the position your product will touch. They are not your competition. They are your distribution channel, your legitimacy layer, and your early adopter base. Design for them first.

3. Treat the next regulatory update as a stress test. If a plausible regulatory update would destroy your business model, you are in the ceiling mindset. If it would accelerate your market consolidation, you have built on the stack.

This framing connects directly to how I think about scope compression in 0→1 work: the constraint you choose to build around determines whether your market shrinks under pressure or compounds.

Most technology companies learn this lesson late. The ones that learn it early build things that last.

Malaysia's property market is not the easiest regulated market in the world to navigate. It is, however, one of the most explicitly architectured, which makes the substrate unusually legible. If you can read the stack, the market opens up in ways that a compliance-first approach will never reveal.

Regulation, read correctly, is not a constraint on what you build. It is the operating system the market runs on.

KG is ACMA, CGMA and General Manager of PEPS Ventures Berhad, where he oversees the product and regulatory strategy for Valuer Copilot, ValuationXchange, and PaymentXchange.