One platform, two depths, set up for your organisation

Your organisation sets the limits

What you may query follows from your legal basis.

Sources with their own legal basis you query yourself, with your PKIoverheid certificate. We open the connection; the query is your organisation’s. For commercial registers, access runs through an agreement with us. Public lists we keep current daily. Open sources you search yourself, within the legal basis of your case.

For every item it stays visible which source it came from. Material from open sources, often called OSINT in investigation work, weighs differently than an extract from a register.

Sources deliver their data in widely varying ways. Noctua brings them into one structure, regardless of how the connection works technically. Technically there is no upper limit to what can be connected; what is available to your organisation remains a matter of powers and agreements.

If a structure runs across the border, the picture does not stop there. Foreign legal entities that emerge from the data appear in the network like the rest. For foreign registers we have an agreement with a data supplier covering more than 430 million companies worldwide in over 200 countries and territories. What of that is available to your organisation follows from your powers and from the agreement underneath it.

Every entity you add is checked. A legal entity goes past different lists than a natural person: sanctions lists, PEP lists, enforcement measures by regulators, permit registers and insolvency registers, and alongside those the rules your organisation has set itself. Which lists are available to you follows from what was agreed during setup.

Every flag can be switched on or off separately, and where it applies you set the threshold value. That choice lies with your organisation, and therefore you can account for it when you are asked to. If there is a flag your work needs and it does not exist yet, we look together at whether and how it can be made.

What someone may view, edit or close follows from their role. Files belonging to one team are not visible to another unless you explicitly set that up. In a Bibob investigation that is not a matter of preference: article 28 of the Bibob Act imposes a duty of confidentiality on anyone who holds data about a third party under that act, and breaching it is a criminal offence.

Fixed rules, no learning system

The same data produces the same outcome.

The duty of care requires that the establishment of facts behind a decision can be followed. The duty to state reasons requires that you make clear what it rests on. That sets a requirement for the way a system arrives at a flag: the outcome has to be explainable.

Noctua therefore works deterministically. Every rule can be written out and checked, and what counts is what your organisation has set. There is no model that learns from earlier files, and there are no connections inferred from historical data.

If you add a company or a person, the platform looks at where that same entity also appears. That happens on unique keys: a Chamber of Commerce (KVK) number, or a name combined with a year of birth. Where there is no key, there is no link. The platform does not guess on resemblance. If you see a connection yourself that no key can establish, you can draw it. It stays visible in the network as your connection, alongside the links that come from the sources.

With sanctions lists it is different. Names appear there in varying spelling and transliteration, and checking on an exact match would miss entries that do matter. Noctua checks more broadly there and reports a possible match, with the entries it found, so that you can establish yourself whether it is the same person.

Navigating through the data

Four views of the same data.

An investigation produces a great many separate facts. Who is a director of what, which company sits under which, when that changed, where it is. In a list you have to hold those connections in your head while you read.

In Noctua you work in the view itself. Every entity is a point you click to see what is known about it, and every connection between two points carries the relationship underneath it. From there you step through to whatever is attached to that.

You look at the same data from the question you are asking at that moment. The network shows all relationships around an investigation. The organisation chart sets out the control structure hierarchically. The timeline puts events in order, so it is visible which roles overlapped. The map shows the entities connected to an address.

Relationships come from the source they came from. If you record a connection you established yourself, it is shown differently, and that action goes into the log. Later it therefore stays visible what you found somewhere and what you inferred yourself.

What ends up in the file

How you arrived at your facts.

Someone challenging a decision rarely takes aim at the outcome alone. The question is which source, which moment, which step.

With every query the platform records which source was consulted, at what moment and by whom, with the search that preceded it. Every finding carries that origin with it. The log registers every action, including opening a file, and cannot be switched off.

If a company or person appears that was included in another investigation, you see that, including which file. Whether you can open that file depends on your rights. The flag is separate from the access, so that you do not duplicate work without breaking the separation between departments.

If your decision is challenged, you do not submit your report alone. Article 7:4 Awb requires you to make all documents relating to the case available for inspection, and on appeal article 8:42 requires the same towards the court. That obligation reaches further than what you used in support.

In Noctua every document ends up with the file: retrieved from a source, supplied by the subject, or added by you. It is placed on the basis of where it belongs. With which investigation, with which entity, and where it comes from a questionnaire, with which question it was submitted in support. That ordering arises while the investigation runs, without you having to build it, and the file shows the documents in that structure. What you did not use in the end stays as well.

The report is your judgement

You can only close when everything has been weighed.

A flag is not a justification. It is a reason to look, and what it means is for you to establish.

The assessment of an alert is yours. Even where you set it aside, that assessment belongs with the file. If something comes up afterwards that changes your judgement, you can return to it. What you recorded as relevant stays visible in the report.

If something is still open, the platform blocks closing. The number of open alerts is therefore a work list: a counter running down to zero while you work through the file. What a check does not turn up is recorded as well, with the moment of checking.

You do not start with a blank page. The report is built while the investigation runs: the fixed sections, the entities and every flag are already in it. Per alert you add what you establish and what you base it on.

When you close, the report is archived and the underlying material is fixed, so that years later it can still be reconstructed as it was then.

After the decision it continues

Monitoring continues in the existing file.

A decision can be revisited later. The facts you base that on are already in the file in which the first decision was taken, in the form in which you established them at the time.

Which entities you keep following, and on what, you set yourself. If something changes that is worth knowing according to your own settings, that alert arrives in the file the entity came from, with the source and the moment. You assess it like any other alert.

Monitoring belongs to the file. Delete it and the following stops, and what you keep stays in the form in which it was built.