BuyerCheck

Building UAE’s Compliance Infrastructure for Real Estate AML

A full-stack SaaS built from scratch for UAE real estate brokers and developers featuring instant buyer screening and enhanced due diligence report generation. Conceptualized, designed, architected, and shipped using AI-assisted development. Currently in testing with two Dubai real estate firms and the Dubai Land Department (DLD).

UAE real estate brokers faced new AML obligations with no practical tools to meet them

In 2025, the UAE enacted Federal Decree-Law No. 10 of 2025, tightening anti-money laundering obligations for Designated Non-Financial Businesses and Professions (DNFBPs), a category that explicitly includes real estate brokers and developers. Under the law, every buyer transaction must now include a formal AML screening, and Suspicious Transaction Reports (STRs) must be filed through the UAE’s goAML portal when red flags emerge.

The compliance requirement was clear. The infrastructure to meet it was not. Most agencies were attempting to manage anti money laundering (AML) obligations through manual Google searches, PDF checklists, and background check platforms with no context to real estate. Enhanced Due Diligence (EDD) reports were often written by hand, outsourced at high cost and slow turnaround, or ignored completely.

The compliance obligation existed. The tooling didn't. Every real estate broker in Dubai was one audit away from a significant regulatory problem, and there was nothing purpose-built to help them.

The result was a market of brokers who were technically non-compliant, aware of their risk, but without a purpose-built product designed for their workflow.

A government official’s frustration reshaped the core architecture

The initial version of BuyerCheck processed screenings asynchronously. A broker would submit a buyer’s details, and results would arrive in a queue. Screenings would be run and reviewed by an attorney, and reports would be delivered to the broker within 48 hours. This felt reasonable at the time. AML screening, to most people’s intuition, is a background check. Background checks take time.

That assumption was challenged directly during a demo with a senior government official. The feedback was specific: in a live transaction setting, brokers do not have two days to wait. A buyer is standing across the desk. The moment has to close. If a compliance check interrupts the moment, agents will find ways to defer it, and deferred compliance becomes non-compliance.

If the broker has to wait, the broker will skip it. Compliance that interrupts the deal is compliance that doesn't happen. The screening had to be instant. Not fast, instant.

This was not a design critique. It was a structural insight about how real estate transactions actually happen. The product redesign that followed made instant processing the non-negotiable foundation of the platform. Screening results now return in seconds, surfaced directly in the broker’s active flow, without requiring a page reload or inbox check.

Closing the gap between regulatory requirement and broker workflow

BuyerCheck is built around interconnected compliance obligations that every UAE real estate broker now carries. They must both screen every buyer against global sanctions and watchlists and produce a defensible EDD report when risk is flagged. Previously, each of these required a separate process, a separate tool, or a separate service provider.

The product thesis is straightforward: if you collapse both into a single workflow, and make that workflow fast enough that compliance doesn’t interrupt a transaction, adoption becomes self-reinforcing. The broker doesn’t choose between speed and compliance. They get both from the same interface.

A service disruption drove the decision to add a fallback AML provider

BuyerCheck’s initial architecture routed all screening requests through a single AML data provider. This worked well during development and early testing. Then a provider-side service disruption took the screening function offline during a period when test users were active on the platform.

The disruption was brief, but the implication was significant. In a compliance context, availability is not a nice-to-have. If a broker cannot screen a buyer because the screening infrastructure is down, the transaction either stalls or proceeds unscreened, both of which create regulatory exposure. A single-provider dependency was an architectural risk that the compliance use case didn’t allow.

Compliance infrastructure that goes down during a transaction is worse than no compliance infrastructure. Redundancy wasn't a technical preference. It was a product requirement.

The decision was made to architect a redundant provider layer with a secondary AML data source. The design pattern is conservative by intention. Both providers are called and the results are merged conservatively, meaning the higher-risk classification always wins when providers disagree. And if Provider A returns an error, the system falls back to Provider B. The failover is invisible to the broker. The compliance output is structurally indistinguishable regardless of which provider answered the request.

Designed, architected, and shipped using AI-assisted development

BuyerCheck was built without a traditional development team. As the deadline was tight and the screening logic very specific, the approach leaned heavily on Claude Code to autonomously execute development phases against detailed product specifications. The workflow established a pattern: define the feature precisely, run an autonomous build phase, verify the output, patch surgically, and ship.

This is not a prototype or a design concept. It is a production application, live on Vercel, auto-deploying from the main branch, with a real Supabase database in the Middle East region, real Stripe payment infrastructure, and real AML API integrations. The AI-assisted development approach made it possible to move from concept to live product at a pace that would have required a three-person engineering team by conventional methods.

The architecture reflects regulatory priorities as much as technical ones. Row-Level Security in Supabase isolates every query by agency_id, ensuring that no broker can access another agency’s screening data. The Middle East-region database placement satisfies data residency expectations. EDD reports are generated server-side and named with a consistent format so compliance archives sort predictably for auditors.

Risk scoring across EDD reports is fully deterministic, with hardcoded weights across six risk dimensions: Sanctions (0–25), Source of Funds (0–25), Reputational (0–20), PEP Status (0–15), Transaction (0–10), and Geographic (0–5). This was a deliberate product decision. Regulators require auditable, repeatable outputs. Black-box AI scoring would be a liability in a regulatory review. The narrative is templated and structured; the numbers are always explainable.

The full workflow a broker completes inside BuyerCheck

Built Deterministic, weighted risk scoring with hardcoded dimension weights. Fully auditable and repeatable. The same input always produces the same score. This was the only viable choice for a regulatory context where brokers must be able to explain outputs to inspectors.

Excluded AI-generated risk scores. Black-box scoring that could not be explained to a regulator was never a consideration. AI tools are inconsistent and can hallucinate. Their “thinking” processes are opaque to the public and thus not usable in a compliance setting.

Built Instant synchronous screening. Results return in the same browser session without a refresh, queue, or email notification. Designed after the government feedback that delayed results would lead to deferred screening and skipped compliance steps.

Excluded Asynchronous screening with email notification. The original architecture delivered results to an inbox. Feedback revealed brokers would not pause a transaction to wait. This model was abandoned before the platform entered broader testing.

Built Dual AML provider architecture with conservative merge logic. Second provider as a hot fallback for any service interruptions. Higher-risk classification always wins when providers disagree. Triggered by a real service disruption during live testing.

Excluded Single-provider dependency. A provider outage during early testing demonstrated that compliance infrastructure with a single point of failure was an unacceptable risk for a regulatory product where availability is a compliance requirement.

Built Government-tier user system with dedicated screening view and CSV export. Allows DLD and other government users to review screening records across agencies without accessing broker-facing features. Scoped and access-controlled by tier.

Excluded A single user type with role-based views. The government use case required architectural separation, not just UI variation. Government users are created manually through a separate provisioning flow with infinite search inventory and tier flags.

Two Dubai real estate firms and the DLD are active on the platform

BuyerCheck is currently in a structured testing phase with two Dubai-based real estate firms conducting active buyer screenings through the platform. The DLD, via a government-tier user account, has live access to the screening view and is engaging with the product as part of a broader evaluation of the platform’s potential as shared compliance infrastructure.

The DLD engagement is significant beyond the immediate testing scope. A long-term goal for BuyerCheck is a government partnership that would position the platform as the compliance layer for the broader UAE real estate market. It could potentially be integrated into DLD’s own regulatory workflows or referenced as the standard tool for RERA-compliant AML screening.

BuyerCheck was conceived, designed, architected, and shipped under my sole product ownership. Every product decision, from the compliance architecture to the EDD report format to the government access tier originated from direct market observation and regulatory research, not a project brief from a client. The GSI Global team identified a market gap, and I built the product to fill it.

The screens below walk through BuyerCheck from search to results and the final report. Each one reflects a specific decision made to keep the compliance workflow fast enough that it never becomes a reason to skip it.

Takeaways

Building BuyerCheck reinforced a principle I hadn’t fully articulated before starting. In compliance products, the user experience and the regulatory requirement are often in direct conflict, and my job is to make them the same thing. When the government official told me that brokers wouldn’t pause a transaction to wait for a result, he wasn’t giving me UX feedback. He was telling me what the compliance rate would be at different latency thresholds. When a provider outage took the platform down during live testing, it wasn’t an engineering problem. It was a product design flaw. A single point of failure in infrastructure where availability is itself a regulatory obligation. Every major architectural decision in BuyerCheck came from treating compliance not as a layer on top of the product, but as the product. That’s the standard I carry into every regulated product.