Banking & Financial Services

You are not asked whether the control exists. You are asked to show that it operated.

Payment instruction changes, credit decisions, fee calculations, transaction monitoring, model governance, third-party risk. Every one is a written rule applied to a flow, under an authority that expects the rule to be demonstrable rather than asserted — throughout a period, including on the occasions when it was not.

Where the decision happens

Records you already keepSpread across the systems you already run.
One finding, with its evidenceDrawn together into a single proposed action.
A person approves itBy name, and nothing goes out before they do.
The work goes outAnd the reason stays on the record.

Where it goes wrong

A break that grows inside the range you always clear

Each month's movement sits within what has been cleared before, so no single month escalates. What is unusual is the three-month sequence, and nobody is reading the sequence.
The verification rule on a payment destination

A change to where money goes is governed by a rule. That rule is enforced in the system, performed by a person following a procedure, or neither — and which one it is has a habit of surfacing after the event rather than before it.
Contracts nobody reads again after signature

Supplier agreements carry obligations on service levels, sub-contracting, data handling and notification. Reading the contract against the relationship you actually have is a comparison at a volume nobody has staffed.
Rate cards applied across a portfolio

Tiers, thresholds and product terms are a reconciliation between what the terms say and what was charged. It gets done periodically, for the same reason as everything else here: volume.

Who owns this

The supervisor's question and the internal one are the same question, asked by different people.

Compliance and risk

The answer moves from "controls were operating effectively during the period" to "here is every exception, when it was found, what was decided and by whom".
Internal audit and control testing

The population tested is the population rather than a sample, and the exceptions come back as named items.
Finance

Where the tier applied and the tier earned differ, and where the accrual differs from what the agreement earns, is stated with the clause it was read from.
Operations

A departure from the plan is noticed while a remedy is still available, instead of becoming a recovery action later.
Security and IT

The model doing the reading runs on your own hardware. The records, the files and the credentials stay on your systems.

What changes

Every finding carries its reasoning, the rule it invoked, the records it cited and a proposed action — and is then graded by a second party on separate credentials, so nothing grades its own work.
Where a finding claims a rate, the counts behind it travel with it and the arithmetic is recomputed. Two readings of the same quantity that disagree are recorded as unable to judge, never averaged into a third figure neither party observed.
The record covers what was allowed, what was refused and what failed — the time, the person by verified identity, the action and the outcome — each entry tied to the one before it, so a later change to the record shows.
Anything that cannot be undone waits for a named person. Where no person is reachable, the gate can be set to refuse rather than to proceed.

How you will know it worked

None of these numbers are ours. They are yours, and most already sit in a report somebody runs monthly. Write down where you stand today before anything starts: the baseline stops being recoverable the moment things improve.

The measure	Your figure today	What moves it
Time to close an audit or regulatory finding	Your issue register — raised date to closure date, for findings closed in the last four quarters. Split those that waited on evidence from those that waited on a decision.	Down on the evidence-bound half, because the record a closure rests on is written as the work happens rather than reassembled afterwards.
Findings open past their due date	The ageing view of that register at last month end: count, original due date, and how many times each item has been extended.	Down, because a control checked on every item can be re-evidenced when the remediation lands instead of waiting for the next testing cycle.
Person-days to assemble evidence for one request	Hours booked against your last supervisory request or audit sample, plus the informal time the business spent finding files. Compare your last two cycles.	Down, and the fall is in the finding rather than the reviewing: the reviewer gets the record made at the time of the decision, not a pack built later to describe it.
Reconciliation breaks and their ageing	Your month-end break report: open items, value bands, days outstanding, and how many were cleared with no cause recorded.	Fewer aged items, and fewer cleared with nothing written down, because every item is read and a run of movements that each sit inside the usual range is raised on the shape of the sequence.
Control-testing coverage and exception rate	Your testing plan for the last cycle: per control, the population in scope against the population actually tested, and the exceptions found.	Coverage toward the whole population, and the exception rate becomes a count of named items rather than an estimate drawn from a sample.
Time from a control failing to somebody knowing	Your last handful of control failures: from the timestamp of the failing event in the source system to the date it first appears in your issue register.	Down, because that gap is the review interval, and judging each item as it arrives removes the wait rather than shortening it.

Two things that make the above possible

The reasoning runs on hardware you own

The records, the contracts and the working-out stay inside your estate. There is no outside model provider in the path, so no customer record, no payment instruction and no draft finding is sent anywhere to be read.

What you would notice

The length of your own third-party risk and model governance review. What is reviewed is software you run, so there is no external service to assess and no data-transfer clause to negotiate. When a supervisor asks how a decision was reached, the answer is a record of what was decided, what it cited and who approved it — held by you.
Reading the open web yourself

Public material — filings, court and registry records, press — is read by a browser running inside your estate, visiting ordinary web pages the way a person would, rather than by a search company acting for you.

What you would notice

Adverse-media and counterparty research, where the question is more sensitive than the answer. Asking an outside vendor whether a borrower is under investigation tells that vendor which borrower you are examining, and leaves that record where you cannot reach it — awkward if the name is market-sensitive or the file later becomes evidence. There is no vendor account here, so no supplier accumulates a history of the names your bank has been asking about.

Who you would be working with

Runink is founder-led. The person in the first meeting is the person who designed the thing being discussed.

Dan Paes

Chief executive and technical founder

Dan Paes has spent more than twenty years inside other people's enterprises, running digital transformation and full-scale modernisation programmes for global organisations. The long kind: what is being replaced is what the business is running on that morning, and the work is judged on whether anything broke.

He founded Runink and runs it as chief executive. Technical founder is the more useful half of that title — he sets the architecture and works in the code, so the person answering an architecture question in a first meeting is the person who decided the answer, and the distance between a question and a change is short.

It is also why the platform is shaped the way it is. It runs on hardware the customer controls, and the reasoning about their data stays there. That is the more expensive way to build it and it closes off the convenient route, which is the kind of decision that has to be settled by whoever owns the architecture rather than left where it can quietly be traded away.

He is a FINOS Ambassador. FINOS is the Fintech Open Source Foundation, part of the Linux Foundation, and the work there is interoperability between institutions that share a market but not their infrastructure and never their data. It is the same problem this platform is pointed at, argued in the open, in front of people who say so when it is wrong.

20+ years

Digital transformation and full-scale modernisation for global enterprises.
CEO and technical founder

Runink. Sets the architecture and writes code in it.
FINOS Ambassador

Fintech Open Source Foundation, a Linux Foundation project. Open source interoperability, in public.

Check any of it

See whether it fits

Bring one control and the systems it is supposed to live in — the verification rule on payment destinations, a supplier agreement, a rate card. A short session is usually enough to see whether the written rule and the applied rule still match.

Book a consultation Read the CORE paper

The long version of the mechanism: what gets read, what a finding contains, how an independent second judgement is formed, and who approves. It carries no case studies, no customer names and no return-on-investment figures.

Where the decision happens

Where it goes wrong

A break that grows inside the range you always clear

The verification rule on a payment destination

Contracts nobody reads again after signature

Rate cards applied across a portfolio