Māori Economy · Productive Capital · Discussion 08
Can technology genuinely reduce the friction between Māori entities and capital?
Yes — but only where the barrier is information, coordination, evidence, data access or execution. Software cannot create willing capital, rewrite law or turn a weak investment into a strong one.
For seven discussions I have deliberately avoided starting with the technology.
That was intentional.
If we begin with a product and then look for a problem to justify it, we will almost certainly exaggerate what software can solve.
So we started somewhere else.
What does the Māori economy actually contain?
Why can access to capital differ?
Why does ownership compound?
Can productive assets support more of their own financing?
Why do complex transactions become difficult to coordinate?
And what should success actually be measured against?
Only now is it useful to ask where Source Code Open Finance and KAURI might fit.
The technology should earn its place by removing a documented barrier. The existence of the technology is not evidence that the barrier has been solved.
First, separate capital supply from transaction friction
This distinction from Discussion 01 remains essential.
Capital supply asks whether there is a lender, investor, guarantor or other capital provider willing to take the risk.
Capital access asks whether a viable entity can reach that capital, present the transaction properly, satisfy the requirements and complete it.
Software can potentially improve the second.
It cannot guarantee the first.
If no lender wants the risk, an application portal does not create a lender.
If a business cannot service the debt, better workflow does not create repayment capacity.
If equity is required, code does not manufacture loss-absorbing capital.
Technology can reduce the cost of getting a good transaction understood. It cannot force somebody to fund it.
The Reserve Bank identifies information problems as part of the barrier
The Reserve Bank's 2025 Māori access-to-capital research identifies information failures and asymmetries as an important part of several barriers facing Māori businesses and entities.
It also identifies low trust and awareness between Māori and the banking system, rural credit frictions, data gaps and the additional complexity that can arise around whenua Māori.
Reserve Bank — Māori Access to Capital: Market Failures ↗
This is exactly where technology deserves examination.
Information asymmetry means one side of a transaction knows something important that the other side cannot easily verify.
The applicant may know the business is strong.
The lender still needs evidence.
The technology question is therefore not:
How do we persuade the lender?
It is:
How do we make the evidence required for a fair assessment easier to assemble, verify, govern and reuse?
Problem 1: the applicant keeps rebuilding the same story
A trust or company seeking capital may repeatedly supply:
entity details,
trust deeds or company information,
trustee or director details,
financial statements,
bank statements,
cash-flow forecasts,
purchase agreements,
valuations,
asset schedules,
and authority documents.
The same information may then be requested again by a broker, lender, lawyer, investor or another adviser.
Where KAURI could help:
KAURI can operate as the applicant-facing transaction workspace.
Instead of beginning every capital conversation with an empty form, the entity could maintain a structured profile containing the information relevant to its current transaction.
That does not mean every participant automatically sees everything.
It means the information can be collected once, classified and disclosed deliberately to authorised participants.
The goal is not “upload once, share with everyone”. It is “collect once where lawful, then disclose the right evidence to the right participant for the right purpose”.
Privacy has to constrain the design
New Zealand's Privacy Act requires personal information to be collected for a lawful purpose connected with an organisation's functions or activities, and only where the information is necessary for that purpose.
The Office of the Privacy Commissioner describes this as data minimisation.
Office of the Privacy Commissioner — Principle 1: Purpose for Collection ↗
That means a capital platform should not collect identity documents, household information or beneficial-owner data simply because it might become useful one day.
Every data field should have a reason.
Every disclosure should have an authorised purpose.
And access should be limited by role.
Problem 2: authority is often harder to understand than identity
Knowing that somebody is Kiri, John or Mere does not prove that they can legally bind a trust or company.
A transaction may require evidence of:
current trustees,
directors,
delegated authority,
board resolutions,
trustee resolutions,
signing rules,
and restrictions in governing documents.
Where Source Code could help:
The platform could model authority as structured evidence rather than relying only on a signature at the end.
A participant should be able to see:
who is acting,
in what role,
under which authority record,
for which transaction,
and whether that authority has been reviewed by the participant responsible for relying on it.
This is a coordination function.
It is not legal advice.
Source Code should never declare a trustee legally authorised merely because a database field says “trustee”.
Identity answers “who are you?” Authority answers “what are you permitted to do?” A serious financial workflow needs both.
Problem 3: financial information is still often assembled manually
Bank statements remain one of the most common ways of evidencing cash movement and account behaviour.
That often means:
PDF downloads,
manual uploads,
spreadsheet extraction,
duplicate requests,
and uncertainty over whether the data is current.
New Zealand's regulated open-banking regime now creates a significant opportunity here.
Open banking changes what is technically possible
The Customer and Product Data Act 2025 and the banking regulations under it create a regulated framework for customers to authorise designated banking data to be shared with accredited requestors in standardised, machine-readable form.
The designated data can include account details, balances, transactions and statements.
MBIE — Open Banking Regulations ↗
The technical standards include security, customer authorisation, identity and operational requirements.
MBIE — Consumer Data Right Standard: Open Banking ↗
For a future capital application, that could eventually allow authorised financial data to enter the workflow directly rather than being reconstructed from uploaded documents.
That could improve:
timeliness,
data quality,
cash-flow analysis,
transaction categorisation,
and evidence of account activity.
But business open banking still has real boundaries
We should not pretend that every trust and company account in New Zealand is immediately available through a universal API.
ASB, ANZ, BNZ and Westpac became designated data holders from December 2025, while Kiwibank's obligations are phased, with payment services from June 2026 and account-information requirements from December 2026.
There are also transitional limits around which electronic banking facilities are covered, and MBIE has continued work on business delegation systems and professional trust accounts.
MBIE — Open Banking Implementation and Business-Channel Transition ↗
So open banking is a genuine architectural opportunity.
It is not yet a complete answer for every commercial applicant.
Problem 4: capital providers receive transactions in inconsistent formats
One lender receives a broker email.
Another receives a PDF pack.
An investor receives a pitch deck.
A guarantor receives a separate memorandum.
Each then rebuilds its own picture of:
the applicant,
the asset,
the cash flow,
the capital request,
the security,
and the risks.
Where Source Code could help:
The transaction could have a canonical structured record.
That does not mean forcing every lender into identical underwriting.
It means the underlying facts can be represented consistently while each provider applies its own credit or investment policy.
For example:
purchase price,
buyer equity,
senior debt requested,
vendor finance,
outside equity,
security offered,
cash-flow history,
and current transaction documents.
Standardise the facts. Do not standardise the judgement.
Problem 5: a capital stack is not one number
Discussion 05 showed why complex acquisitions may need several forms of capital.
If a transaction contains:
senior debt,
subordinated debt,
vendor finance,
equity,
and a guarantee,
the software needs to represent each instrument separately.
Where Source Code could help:
Each capital instrument can have its own:
provider,
amount,
status,
term,
pricing,
security,
priority,
conditions,
and settlement requirement.
Then the platform can answer a question that email cannot answer reliably:
Is the entire capital stack ready, or only one part of it?
Problem 6: conditions precedent are fragmented across people
Discussion 06 showed that an approved transaction may still be blocked by:
insurance,
valuation,
resolutions,
legal documents,
security,
proof of equity,
AML/CFT,
vendor requirements,
or another capital provider.
Where Source Code could help:
Every material condition should become a governed object with:
a description,
an owner,
a reviewer,
evidence,
status,
due date,
version history,
and a flag showing whether it blocks settlement.
That converts the transaction from:
“I think we're waiting on the lawyer”
to:
“Condition CP-14 remains outstanding; applicant's lawyer is responsible; lender must accept the evidence; settlement is blocked until acceptance.”
This is where workflow software can create measurable operational value.
Problem 7: documents and transaction state get confused
A signed PDF tells us what was agreed.
It does not necessarily tell us what stage the transaction has reached.
Where Source Code could help:
Documents should be linked to the state they support.
A valuation can satisfy a valuation condition.
A trustee resolution can support an authority condition.
A signed facility agreement can satisfy a documentation condition.
The platform then knows not only that a file exists, but what role it plays in the transaction.
A document repository stores evidence. A transaction system understands why the evidence matters.
Problem 8: participants should not share the same authority
The current Source Code design already contains an important governance principle:
no single participant controls the entire transaction.
That principle is worth preserving.
The applicant supplies information and gives its approvals.
The broker or adviser structures or places the finance.
The lender decides credit.
The lawyer completes legal work.
The vendor completes the sale side.
Settlement happens only when the required authorities and conditions align.
Where Source Code could help:
Role-based permissions can prevent one participant from impersonating another participant's decision.
The applicant should not mark the lender's credit condition approved.
The lender should not mark the lawyer's legal certification complete.
The platform operator should not silently override either.
This is one of the strongest reusable ideas from the earlier financial systems we built: material actions should have explicit authority, durable state and an audit trail.
Maker-checker controls can extend beyond payments
Maker-checker is normally associated with payment and treasury controls.
But the broader principle is useful here.
One participant prepares.
Another participant verifies.
An authorised participant approves or releases.
That can apply to:
changes in bank account details,
capital commitments,
settlement instructions,
changes in purchase price,
release of conditions,
or other high-impact transaction events.
The exact control should be proportionate to risk.
Not every field edit needs three people.
Problem 9: AML/CFT evidence is duplicated, but cannot simply be centralised away
DIA's 2026 AML/CFT guidance now contains updated material on beneficial ownership, companies, trusts, enhanced customer due diligence, outsourcing and reliance on another reporting entity.
Department of Internal Affairs — AML/CFT Trust and Company Service Providers ↗
The important word here is reliance.
There are lawful circumstances in which one reporting entity may rely on another for aspects of customer due diligence.
But that is not the same as saying:
“KAURI verified them, therefore everyone else is done.”
Each regulated participant retains responsibilities under the law and the specific reliance arrangement.
Where the technology could help:
record what evidence exists,
who obtained it,
when it was verified,
what reliance basis is being used,
what remains outstanding,
and which reporting entity is responsible for the final decision.
Compliance evidence can be coordinated. Compliance responsibility cannot simply be transferred to software.
Problem 10: settlement needs stronger state control than email can provide
The most valuable parts of the earlier NSB payment architecture were not the branding around banking.
They were the transaction-control patterns underneath it.
Those patterns included:
authenticated actors,
role-based authority,
validation,
duplicate prevention,
maker-checker approval,
durable records before external submission,
and explicit accepted, rejected or pending states rather than pretending that a technical response means final settlement.
Those ideas translate well into a commercial-finance workflow.
Where Source Code could help:
the transaction should not move to “settled” merely because somebody clicked a button.
Settlement should require:
authorised release,
confirmed conditions,
stable payment or settlement references,
reconciliation,
and a final audit state.
A green screen is not settlement. Settlement is an externally verifiable change in financial and legal state.
Problem 11: the system currently lacks enough outcome data
The Reserve Bank describes its Māori Access to Capital snapshot as a baseline built from the data currently available on a voluntary, best-endeavours basis.
It explicitly says improved data is important for monitoring system efficiency and progress in reducing unnecessary barriers.
Reserve Bank — Māori Access to Capital Snapshot ↗
Discussion 07 showed what a productive-capital evidence layer might eventually measure.
Where Source Code could help:
applications started,
applications completed,
capital requested,
offers received,
declines,
withdrawals,
conditions causing delay,
time to decision,
time to settlement,
capital structure,
ownership retained,
and eventually post-settlement outcomes.
That creates the possibility of distinguishing:
no capital available,
poor credit quality,
collateral shortage,
information failure,
legal delay,
governance delay,
and operational failure.
But outcome data must not become surveillance
A productive-capital evidence system needs strong boundaries.
The fact that data could be collected does not mean it should be collected.
Applicants should understand:
what is being collected,
why,
who can access it,
how long it is retained,
what aggregate reporting may occur,
and what uses are prohibited.
Where data is used for broader economic analysis, aggregation or de-identification should be considered where appropriate.
Māori organisations should also have a meaningful governance role in decisions about how Māori transaction data is reused beyond the immediate financing purpose.
Technology may also improve trust — but only indirectly
The Reserve Bank identifies low trust and awareness between Māori and the banking system as part of the access-to-capital problem.
Software does not create trust by itself.
A beautiful interface attached to the same opaque process may actually make distrust worse.
Technology can support trust when it creates:
clear requirements,
visible transaction status,
named responsibility,
consistent evidence,
transparent decisions,
and an auditable record of what happened.
Transparency can support trust. It cannot substitute for fair behaviour.
Technology cannot solve an unsuitable capital product
Suppose the only available capital is:
too expensive,
too short-term,
too highly secured,
too dilutive,
or inappropriate for the asset being acquired.
Source Code can present that product perfectly.
It is still the wrong capital.
This is where specialised lenders, patient equity, guarantees, co-investment or policy intervention may be required.
Technology cannot solve insufficient equity
If a $5 million acquisition can safely carry only $2.5 million of debt, the other $2.5 million has to come from somewhere.
No workflow can change that arithmetic.
The gap might be filled by:
buyer equity,
vendor finance,
outside investors,
subordinated capital,
or some other risk-bearing instrument.
The software can coordinate the structure.
It cannot become the missing equity unless a real capital provider stands behind it.
Technology cannot rewrite the legal characteristics of whenua
Discussion 03 established that whenua Māori can be mortgaged, but its governance and ownership structure can make the financing pathway different.
Reserve Bank — Lending on Whenua Māori ↗
Source Code could make the required authority and transaction steps clearer.
It cannot amend Te Ture Whenua Māori Act or make the recovery characteristics identical to ordinary general-title land.
That distinction matters.
Technology cannot make a weak business good
This is the most important underwriting boundary.
If the business has:
declining revenue,
poor margins,
unmanageable debt,
weak management,
an inflated purchase price,
or no credible path to repayment,
the correct outcome may be:
do not fund the transaction.
Financial inclusion does not require approval of bad investments.
It requires viable applicants to have a fair opportunity for their risk to be understood correctly.
The purpose of better infrastructure is not to make more deals pass. It is to make the right deals easier to assess and the wrong deals easier to identify.
So what should KAURI actually be?
I would keep its role narrow and clear.
KAURI should be the applicant workspace.
It should help an eligible trust or company:
build its entity profile,
identify the productive asset it wants to acquire,
submit financial and governance evidence,
authorise appropriate data access,
review proposed finance,
complete applicant actions,
and see transaction status.
It should not pretend to be the lender.
It should not make legal decisions.
It should not advertise “instant approval” where the transaction genuinely requires human assessment.
And what should Source Code actually be?
Source Code should be the governed transaction layer.
It should connect:
the applicant,
broker or adviser,
one or more capital providers,
lawyer,
vendor or agent,
and settlement participants.
Its core responsibilities should be:
transaction state,
role-based access,
capital-stack representation,
condition management,
document-to-condition linkage,
authorised approvals,
exception handling,
settlement readiness,
reconciliation,
and auditability.
This is materially different from “another loan application website”.
The platform should reduce transaction cost
That is ultimately the commercial and economic test.
If Source Code requires every participant to perform more administrative work than before, it has failed.
The platform should seek to reduce:
duplicate data entry,
document chasing,
status meetings,
manual reconciliation,
version confusion,
missing conditions,
and avoidable settlement delay.
Then measure whether those costs actually fell.
The platform should reduce uncertainty
At any moment, an authorised participant should be able to answer:
What is the transaction?
What capital is committed?
What is still conditional?
Who owns each outstanding action?
Which documents are current?
What blocks settlement?
What changed?
And who approved the change?
That is a far more useful definition of fintech than simply moving an existing paper form onto a screen.
Open banking creates a real future integration path
As New Zealand's regulated open-banking regime matures, there is a credible opportunity for applicant-authorised banking data to become part of commercial underwriting and monitoring workflows.
MBIE says regulated open banking now supports secure data sharing and payment initiation under the Customer and Product Data Act framework.
By August 2026, regulated open-banking payment volumes were already increasing materially, although the commercial-account use cases and delegated business-authority questions continue to develop.
MBIE — Regulated Open Banking Gains Momentum ↗
This is exactly the kind of public infrastructure Source Code should integrate with rather than attempt to recreate.
Build orchestration where the market is fragmented. Integrate with regulated infrastructure where good infrastructure already exists.
A practical build order
If I were prioritising the technology against the problems established in this series, I would build in this order.
1. Entity and transaction profile.
Who is applying, what are they acquiring, and what capital is required?
2. Evidence and authority.
What proves identity, governance, financial position and authority?
3. Capital-stack and condition engine.
Who is providing what, under which terms and subject to which conditions?
4. Multi-party workflow and permissions.
Who can submit, review, approve, certify and release each action?
5. Settlement-readiness and audit layer.
What must be true before completion, what actually happened, and can it be reconstructed afterward?
6. Open-banking and external-data integrations.
Bring verified external information into the transaction where the law, accreditation and account coverage permit it.
7. Outcome measurement.
Only after real transactions exist should the platform begin building meaningful longitudinal evidence about access, completion and productive outcomes.
Do not build an AI credit oracle
Artificial intelligence may eventually help with:
document classification,
data extraction,
missing-information detection,
summaries,
workflow assistance,
and anomaly flagging.
But I would be extremely cautious about presenting AI as the decision-maker for Māori access to capital.
A model trained on historical credit decisions can reproduce historical patterns without understanding why they existed.
The final credit, legal and investment decisions should remain attributable to authorised humans and institutions.
Automation should make the evidence easier to examine.
It should not make accountability disappear behind an algorithm.
How would we know if the technology worked?
Not by counting users.
Not by counting uploads.
Not by counting screens.
I would look for:
less duplicate information collection,
fewer incomplete applications,
shorter time to capital decision,
shorter time from approval to settlement,
fewer conditions lost in email,
lower professional transaction cost where comparable,
more complete evidence for lenders and investors,
clearer reasons for declines and failed transactions,
and ultimately more viable productive transactions reaching settlement.
Then Discussion 07's measures tell us whether those transactions actually strengthened Māori ownership and balance sheets afterward.
My conclusion
Yes, technology can genuinely reduce friction between Māori entities and capital.
But the useful part is much narrower and more disciplined than saying “fintech will solve Māori access to capital”.
Technology can reduce:
information asymmetry,
duplicate data collection,
document fragmentation,
authority confusion,
condition-management failure,
transaction-state uncertainty,
settlement coordination problems,
and some of the data gaps that prevent us from understanding where transactions fail.
It cannot create:
a willing lender,
patient equity,
a guarantee,
repayment capacity,
good management,
appropriate law,
or a viable investment.
Software can make a viable transaction easier to understand, govern and complete. It cannot make an unviable transaction viable.
That is the standard I would hold Source Code Open Finance and KAURI to.
Not whether they look innovative.
Whether they remove measurable friction from real productive-capital transactions without weakening underwriting, legal responsibility, privacy or control.
Next
That leaves the final problem in this phase of the series:
What still requires policy, specialised capital or institutional reform rather than software? →
Discussion 09 separates the remaining barriers into those that require lenders and investors, guarantees and equity, legal or regulatory reform, institutional capability, Māori governance, public policy and market development — so we do not keep asking technology to solve problems that belong somewhere else.
Primary sources
Reserve Bank — Māori Access to Capital: Market Failures ↗
Reserve Bank — Māori Access to Capital Snapshot ↗
MBIE — Open Banking Regulations ↗
MBIE — Consumer Data Right Standard: Open Banking ↗
MBIE — Regulated Open Banking Gains Momentum ↗
Office of the Privacy Commissioner — Privacy Principle 1 ↗