Registry Direct is a share registry where companies and trusts can self-manage their registers.

One of the requests from clients was to allow them to manage a Dividend or Distribution payment, enabling them to generate payments for their shareholders.

What capability were we aiming to build?

Companies and trusts often pay their shareholders a percentage of their earnings. The idea behind this feature was to allow our clients to easily calculate each individual payment for each shareholder.

To receive a payment as a shareholder, you need to own shares on a specified date. The more shares you own, the larger the payment, since your payment is based on each unit you own.

It was easy for us to determine how many units a shareholder owned and how much their final payment would be, based on the price per unit.

Ultimately, the company/trust wanted to be able to easily calculate how much each shareholder would receive and transfer that amount to the shareholder's bank account.

Some of the challenges

From my initial conversations with stakeholders, all we had to do was multiply the number of units a shareholder owned by the pence per unit that our client entered in the setup form.

Although that calculation is correct, there are many other factors to consider in what we call a "Payment cycle."

The "Payment cycle" was a way of setting a start and end point for the entire process, from setting up a payment for all your shareholders to actually making the payment to their bank accounts.

Some other factors we needed to consider were how much tax needed to be withheld from each shareholder, depending on their country of residence or whether they had supplied a TFN. Also, if the shareholder has a bank account, did we send them a cheque, or did we withhold the full amount?

Many of these variables had to be left up to our clients, so we needed to give them the flexibility to choose what the system did based on the shareholders' settings.

Our biggest challenge was to provide this feature for trusts so they could pay a distribution. Trusts need to be able to define each component of a payment, and each component has a different set of properties that affect each shareholder's individual payments.

Since this was beyond our expertise, we contracted Ernst and Young to help us define each possible component and how each of them works. For example, for some components, you are meant to withhold tax, while for others, you are not. Additionally, for some components, there may be a treaty between countries where you calculate a smaller percentage of tax.

A single payment can have multiple components, so stitching it all together to calculate the correct amount for someone to be paid and their tax withheld wasn't easy.

Design and build process

We started by allowing only companies to pay dividends since it was a more straightforward challenge with fewer unknowns. Once we perfected the dividend payment cycle, we were ready to move on to distribution payments for trusts.

The challenge here was to ensure that we applied all the tax rules properly, based on what E&Y had provided us through their documentation. It was essentially a series of spreadsheets that needed to be distilled into rules that the development team could incorporate into the payment cycle.

Since this was a complex feature, we initially released it to a designated set of clients to gather feedback and iron out any bugs.

We also organised some training sessions for some of our major clients to help them become more comfortable with the process.

Registry Direct holds a database of individuals, companies, and trusts with all their associated details.

Under Australian law, companies and trusts on the platform are legally required to verify the identity of shareholders before accepting any investments. Historically, this process was entirely manual — managed outside the platform through document submissions.

What capability were we aiming to build?

Our clients needed a streamlined way to verify new shareholders without running a separate compliance workflow outside the platform.

The goal was to give them a single in-platform path to satisfy AML and CTF requirements prior to accepting an investment, covering both Australian/NZ investors via an automated identity check, and international investors via a structured manual review.

Some of the challenges

We evaluated multiple providers before settling on GreenID by GBG, the most stable API with the best documentation. But GreenID only covers Australian and NZ investors, so we needed a fallback for international shareholders.

Given the low volume of international investors, we decided a manual verification path (scanned documents) was defensible, even though some clients pushed for a fully electronic solution. The cost of a second API for a small subset was hard to justify.

Verification failures added another design challenge. They can be legitimate (a name that genuinely doesn't match) or benign (a recently changed address). The design had to give clients context to make a judgement call, and a path to manually override or re-verify.

Design and build process

We deliberately waited on prototyping until we fully understood what the GreenID API could and couldn't do. Once we had a clear picture, we built prototypes and ran facilitated sessions with a select group of clients.

These sessions surfaced edge cases around partial verification states we hadn't anticipated, which fed directly back into the design before release.

The end result was that clients could now manage all AML and CTF requirements within Registry Direct prior to accepting investments, compliant with Australian law, with no need to manage multiple systems.

Registry Direct's clients (companies and trusts) regularly release new investment offerings to the public.

Historically, this was managed through PDF forms and manual payment coordination. A client would create a PDF describing the opportunity, attach a paper form, and then manually reconcile each investment against bank transfers.

Since our clients' investors were already on the platform, we had an opportunity to replace that workflow with a digital application form that could handle investment amounts, investor details, and payment in one place.

What capability were we aiming to build?

The goal was a white-label form builder where clients had full control over branding, rules and minimums without needing us for every change request.

Investors should be able to apply, supply their details, and pay in a single flow, while clients had a back-office to manage the offering and track applications.

Some of the challenges

Our first iteration generated forms on demand. A client asked, we built it and shared the URL. This was unsustainable. Change requests were too frequent and too fiddly to manage at scale.

Handling existing investors was the more significant challenge. Most people investing in a raise were already shareholders. Allowing them to apply without creating duplicate records required careful identity matching logic, which shaped how we designed the investor-facing flow.

Payment management added complexity. Clients needed to mark when money arrived, reissue invoices, and generate receipts. We had to design a back-office workflow that matched how these clients actually operated.

Design and build process

We ran extensive consultations before designing anything. The variety of ways different companies run capital raises was wider than we'd assumed. Some required strict minimums, others soft; some collected payment upfront, others invoiced later.

That variety drove the decision to build a form builder rather than fixed templates. We used Rubix as the underlying framework and iterated heavily on the builder UI.

The first version was powerful but intimidating. Subsequent rounds focused on reducing cognitive load for first-time users, simplifying the configuration surface and improving defaults.

Some of the world's largest banks, NAB, ANZ, UBS, and Standard Chartered, use Feedzai to prevent financial crime and automate customer verification.

In V1 of the Feedzai Orchestration Solution, building and configuring these automated workflows required an engineer. Every new data source, every logic change, every tweak to a decision rule meant a ticket, a handoff, and a wait.

What capability were we aiming to build?

When a bank onboards a new customer, they need to verify their identity, screen them against sanctions and PEP lists, assess fraud risk, and make a decision, often in seconds.

FOS automated that process by connecting data sources and orchestrating the logic between them. But in V1, the only people who could build and modify those workflows were engineers. Business analysts, the people who actually understood the compliance rules and verification logic, had no way to act on that knowledge directly.

The goal for V2 was to give analysts a visual, low-code canvas to configure data sources, build workflow logic, and publish changes, without writing a single line of code or raising an engineering ticket.

Some of the challenges

The biggest challenge wasn't building the canvas. It was deciding how much complexity to expose.

Engineers working in V1 had full control. Every parameter, every authentication detail, every transformation was explicit. Business analysts didn't need that level of control, but they did need enough. A BA configuring a sanctions check still needs to understand what data is being sent, what comes back, and what happens when it fails.

Strip too much away and the tool becomes a black box they can't trust. Leave too much in and you've just moved the complexity from an API config file to a screen.

The second challenge was the data itself. Banks connecting to external providers for the first time, identity services, sanctions lists, credit bureaus, were getting back responses in completely different formats. Analysts needed a way to transform and normalise that data before it could flow through a workflow, without writing SQL or code from scratch.

Finally, trust. Engineers could read a stack trace and debug a failed workflow. Analysts couldn't. If something went wrong in a live verification run, they needed enough visibility to understand what happened and fix it, without calling an engineer.

Design and build process

We started by mapping what engineers were actually doing in V1, the sequence of steps, the decisions they were making, the mental model they were working from. That became the foundation for the canvas. We weren't designing from scratch; we were making an existing process visible.

Early prototypes focused on the source configuration flow, the entry point for everything else. If analysts couldn't connect a data source confidently, nothing downstream mattered. We tested with analysts at client institutions and found that the hardest part wasn't the technical fields, it was not knowing whether the connection had worked. Feedback and validation states became a significant design focus.

The canvas itself went through multiple rounds of iteration. Simple linear workflows were intuitive from the start. Branching logic, if/else conditions, parallel sources, layered transformations, was harder to represent without overwhelming first-time users. We introduced progressive disclosure, surfacing advanced options only when needed, so the default experience stayed approachable without sacrificing power for complex use cases.

Testing and simulation were built directly into the canvas. Before publishing a workflow, analysts could run it against sample data and see exactly which nodes fired, what data passed through, and where failures occurred. This was the trust mechanism. It gave analysts the confidence to publish without needing an engineer to sign off.

The result was a platform where business analysts at some of the world's largest financial institutions could go from a compliance requirement to a live, automated verification workflow, without engineering involvement for every change.