A chance to test an alert for future cash shortfalls

Twelve weeks of testing with financial data

The Financial Services Commission, South Korea’s financial policymaking and supervisory agency, and the Korea Fintech Support Center are recruiting participants for the second half of 2026 D-Testbed programme (D-테스트베드) until 5:00 p.m. on September 8. Companies, prospective entrepreneurs, individuals, and teams can all apply. Fifteen teams will be selected across a general track and an artificial intelligence track.

Selected teams will analyse linked financial and non-financial data for 12 weeks, from September 21 to December 11. The 12 weeks are access to the testing environment, not the period covered by the data. The available data history has expanded from up to three years to up to five years.

Data cannot be downloaded to a personal computer. It is handled in a remote analysis environment: a separate computer system that users access to examine data without taking it outside. Teams can also bring in their own data for joint analysis if it has been pseudonymised or anonymised so that individuals cannot be directly identified.

The artificial intelligence track also provides high-performance hardware for complex calculations. Collaborative projects include financial support for small business owners, customer-demand forecasting, and alternative credit assessment. Public-interest projects include anti-money-laundering, transfer-pattern analysis, and evaluation of test data designed to resemble transaction patterns.

D-Testbed began as a pilot in 2021, and 170 teams had participated by the end of 2025. According to the Financial Services Commission, this led to 22 service launches, four financial-regulation special-exception designations, and eight commissioned testing contracts with financial companies. However, check the call-for-applications attachments and operating guidelines to confirm what raw data and analysis-result files, if any, may be taken outside the environment.

Show the date of the shortfall, not the whole set of accounts

At least at the idea-validation stage, D-Testbed lowers this data barrier.

Picture the owner of a window-and-door installation business with 12 employees. Each morning, the owner checks the bank balance, looks up expected project payments in a phone memo, and enters material costs and payday again into a spreadsheet. Bank transactions, tax invoices, and project schedules are separate, so the same amounts are copied several times.

The problem is not that the accounting ledger is wrong. It is discovering too late that, if a client payment arrives three days late, Friday’s material payment will overlap with next week’s payroll. The owner responds only after the shortage appears, by calling the client or putting in personal money.

The piece to carve out is not a full accounting service. It is a screen that shows the dates when the balance may fall short in the next 14 days. It does not file taxes, process payments, or recommend loans. It shows only around three dates that need attention by comparing when money is expected to come in and go out.

In a test version, up to five years of transaction flows can be used to examine payment intervals, recurring spending, and seasonal differences. The screen could show “Expected balance shortfall on November 24” alongside the reason: “Possible delay in project payment before payroll.” Instead of reading the full ledger, the owner chooses one action: confirm the payment date, change the payment date, or secure spare funds.

Some work still has to stay with people. Data alone cannot tell you whether a project payment will actually arrive, whether a material order can be delayed, or what was agreed with a client. The service should not make the decision. It should only narrow down which client the owner needs to call first and which amount needs checking.

A narrower scope also makes the first customer clearer. Do not begin with every business that wants to replace multiple banks and ledgers at once. Start with small installation businesses where payment dates and payroll dates frequently fail to line up. Customer consent and personal-data protection requirements for commercial use need separate confirmation. D-Testbed is for idea validation, and any approvals required for commercial launch must also be confirmed separately.

Abroad, teams validated smaller features first

The UK Financial Conduct Authority’s Digital Sandbox lets early-stage financial businesses test services with synthetic data that resembles real people but is not based on identifiable individual records, as well as public and anonymised data. Its first pilot received 94 applications over four weeks and selected 28 participants. Test-data requests exceeded 850,000. Ninety-two percent of participants identified synthetic data as the most important element.

Based on the results of several pilots, the UK Financial Conduct Authority made the environment a permanent service in August 2023. It did not disclose participation costs, and the programme is different in nature from a standard paid data-sales service.

Australia’s Consumer Data Right Sandbox is a free tool for companies building bank-connection services. It lets them practise connection processes with simulated financial institutions and test data before live operation.

The tool is still operating, but it has not disclosed how many participants went on to launch real services or generate revenue. A test environment reduces development failures; it does not, by itself, prove customer demand.

Qapital in the United States connects accounts with customer consent, then sells a feature that automatically sets money aside when a specific payment occurs or a goal condition is met. It is an example of focusing not on an entire bank app but on one piece: savings based on everyday rules.

Qapital charges US$3, US$8, or US$12 per month depending on the feature set. The company and account-connection provider Plaid said that 1.7 million users had saved more than US$1 billion in total, though these are self-reported figures. Even when a feature has been validated in a free testing environment, commercial launch requires a separate check of who will pay every month.

Four features to carve out and test now

1. A calendar of project-payment gaps

• What it does: Overlays expected payments and recurring expenses, then marks dates in the next 14 days when money may run short.
• Who uses it: The owner of a construction or installation business with five to 15 employees, where project payments arrive later while material costs and payroll must be paid first.
• Why now: Multi-year transaction flows can test whether delayed payments and recurring spending can be distinguished without first partnering with a financial institution.
• First screen: Show only today’s balance, the projected balance over 14 days, and three incoming payments to check.

2. A living-expense line for irregular income

• What it does: Shows people with different monthly income how much they can spend on living costs until their next payment.
• Who uses it: A freelance video editor paid by three platforms, with no fixed payday.
• Why now: It can test whether seasonal income and fixed expenses can be separated in data covering up to five years.
• First screen: Show the next expected payment date, essential spending until then, and the daily amount available to spend.

3. A suspicious-transfer review queue

• What it does: Selects transfers that differ from normal patterns in time, amount, or frequency, then sets the order in which advisers should review them.
• Who uses it: A customer-support team at a regional financial company handling transfer enquiries from older customers and reports of financial fraud.
• Why now: Transfer-pattern analysis and test data that resembles transaction patterns are listed as public-interest projects, allowing teams to compare detection criteria.
• First screen: Show review priority, what changed from the usual pattern, and three questions to ask the customer.

4. An income-flow summary card

• What it does: Summarises uneven payment records through income continuity, gaps between payments, and the share of essential spending, without deciding whether to approve a loan.
• Who uses it: A staff member at a small financial company advising delivery drivers and freelancers whose circumstances are hard to explain through a credit score alone.
• Why now: Linked financial and non-financial data can first be used to compare whether explanation factors beyond existing scores are useful.
• First screen: Show a calendar of payments over the past 12 months, the longest income gap, and documents the staff member should check.

Why this matters where you are

Korea’s D-Testbed is a Korean public testing environment, with its own data-access rules, financial regulation, and support structure. In your market, check whether a comparable sandbox, open-data programme, or synthetic-data environment exists, and what it permits. Wherever you are, the transferable lesson is to test one narrow financial decision before trying to replace an entire accounting or banking workflow.

One thing to check today

Open the D-Testbed call’s data specification and check whether you can follow the transaction date, incoming and outgoing amounts, and balance for the same anonymised user across at least 12 months. If those three fields are connected, a test version that calculates cash-shortfall dates is worth trying. If balances or chronological order are missing, drop the first idea and choose another piece.