PHANTOM CHECK / SOURCE-BASED REVIEW

Review what the evidence supports.
Identify what remains open.

Phantom Check is a source-based review within an agreed scope. At the initial contact, we clarify the purpose and scope. The result is a dated report (dossier) with a record of the sources consulted, which you can read, review and share. On request, we independently examine applications and systems in depth: code, functionality, performance and security.

A dated report with sources, findings and outstanding evidence.

Describe your question View a sample dossier
More details

Phantom Check is a source-based review within an agreed scope. At the initial contact, we clarify the purpose and scope. The result is a dated report (dossier) with a record of the sources consulted, which you can read, review and share. On request, we independently examine applications and systems in depth: code, functionality, performance and security.

Context The six review groups contain possible questions and examples; they do not provide comprehensive coverage. The scope and sources are agreed for each review. The report does not guarantee approval.

REVIEW PRINCIPLEExample workflows · fictional
Sources
  • Q1Submitted document
  • Q2Publicly accessible information
  • Q3Additional source
ComparisonCross-check
DossierDateAssessment
  • Supported: confirmed in the sources
  • Inconsistent: sources differ
  • Pending: evidence missing
SIX GROUPS OF POSSIBLE REVIEW QUESTIONS

What a review
can cover.

Examples, rather than comprehensive coverage: not every assignment needs every group. At the initial contact, we establish which questions matter in your case, along with the purpose, scope and available sources.

01

Companies and business partners

Possible review question
Does the company exist as it presents itself? Do the name, registered office, representation and ownership details agree across the sources?
Source base
Publicly accessible registry and company information, and documents provided by the client.
Limit
Information that is not publicly available cannot be assessed.
02

Individuals / KYC

Optional · only for a legitimate purpose
Possible review question
Do the stated roles and identity details of contact persons match the documents provided?
Source base
Information supplied by the client and publicly accessible sources, only where the purpose is documented and legitimate.
Limit
KYC is one component. Banks remain responsible for their own reviews; no identity or bank documents are requested through this form.
03

Documents and sources

Possible review question
Are the issuer, date, content and provenance of a document consistent, both internally and with one another?
Source base
Submitted documents compared with additional sources.
Limit
No guarantee of authenticity or expert determination; irregularities are identified, rather than “proven”.
04

Business processes and transactions

Possible review question
Are the roles, sequence of steps and requested evidence in a transaction clear and complete?
Source base
The described process, draft contracts and offers, and correspondence where authorised.
Limit
No payment processing, legal, tax or financial advice.
05

Markets, economics and scenarios

Possible review question
How does a project fit into its market environment, and which assumptions support each scenario?
Source base
Published market information, stated assumptions and qualitative scenarios.
Limit
Scenarios are frameworks for thinking, rather than forecasts or promises of returns.
06

Technology, systems and processes

Within an agreed scope
Possible review question
How are authorised systems, configurations, interfaces or processes structured, and where do an in-depth review of code, configuration and architecture or targeted security tests reveal identifiable gaps?
Source base
Prerequisite: an agreed purpose, plus a subject, scope and suitable review access expressly authorised by the person entitled to do so.
Limit
Targeted security tests only with express authorisation and within the agreed scope; no certification, no guaranteed full coverage, no security assurance.

Example outputs: Read a fictional sample dossier View the technical review

REVIEW PRINCIPLEExample workflows · fictional
  1. Sources
  2. Comparison
  3. Dossier
REVIEW PRINCIPLE

Sources become
a traceable finding.

Sources

  • Q1 Submitted document
  • Q2 Publicly accessible information
  • Q3 Additional source

Comparison

Each statement is recorded by source, with a date. Matches and differences are set out side by side.

Dossier

  • Supported: confirmed in the sources
  • Inconsistent: sources differ
  • Pending: evidence missing
Diagram of the review principle. The three assessments are categories, rather than a numerical score.
TECHNICAL DEPTH

Independent technical review.
Performance and security.

We offer in-depth technical reviews on request. The report identifies affected areas, risk, priority and concrete remediation. We document test steps and reproduction conditions where the test objective and access allow. Corrected items can then be checked in a targeted follow-up review.

01

Code and configuration

Subject
Authorised source code, configurations, and permission and dependency structure.
Result
Identified weaknesses, insecure settings or uncertainties are documented with the affected location, risk, priority and concrete remediation.
02

Interfaces and architecture

Subject
Interfaces, data flows, role and permission concept, and the structure and dependencies of the system.
Result
Assessment of weaknesses and assumptions in the design, with risk, priority and a remediation proposal.
03

Security and load testing

Subject
Defined security, load and stress tests, together with suitable functional, error and edge-case tests on authorised applications or systems. Objectives, environment, methods, load profiles, intensity and stopping criteria are agreed in advance.
Result
Depending on the assignment: response times, error rates and resource usage, alongside traceable security findings. Reproduction conditions are documented where possible. Retesting of corrected items is agreed with its own scope and date.

Purpose, scope, authorisation and suitable review access are agreed in advance. Code, review access and test data follow only afterwards via a suitable exchange channel; access credentials or keys do not belong in the initial contact form.

View the fictional technical example

DOSSIER STRUCTURE

How the result
is presented.

Every dossier follows the same structure. This makes it clear what was reviewed, what it is based on and what is still missing.

Dossier · review of an offer documentExample · fictional, anonymised information · no real case
01 Date
Review status and source access dates (placeholders in this example).
02 Scope
Question and subject: whether the sender, company information and role in an offer letter match up.
03 Sources
Q1 client's offer document · Q2 publicly accessible registry details · Q3 company's website.
04 Findings
Company listed in Q2. Name matches in Q1 and Q2. Signatory's role not confirmed in Q2.
05 Inconsistencies
Registered office details in Q1 differ from Q2.
06 Missing evidence
Signatory's power of attorney. Current confirmation of availability from the other party.
07 Qualitative assessment
Partly supported by evidence: the company appears plausible, but authority remains unconfirmed. No statement on the authenticity of individual documents or the ability to deliver.
08 Next steps
Request power of attorney, clarify the registered office discrepancy, then update the dossier with a new date.
Anonymised example, expressly not a client case. The assessment is qualitative; there are no scores or approval seals.
Technical finding · fictional test applicationFictional example · not a client finding · no test performed
01 Subject
Purely fictional test application with an invented API, invented test roles (“Role A”, “Role B”), test data and sources; authorisation and review access are invented for the example.
02 Finding
Missing authorisation check at API resource level: when a record is retrieved, it is not verified whether the signed-in user or their role may access exactly that resource.
03 Reproduction
Signed in as test role B, retrieve an invented test record of role A via its resource identifier. In the example, it is returned. Only invented test data is used, no real endpoints.
04 Risk and priority
High (qualitative assessment, not a score): data of other users or roles would be viewable.
05 Remediation
On every retrieval, check server-side whether the signed-in user or their role may access the requested resource; deny by default and secure the rule with a test case.
06 Follow-up check (optional)
On request, the specific corrected item is checked again with the same test roles, with scope and timing agreed separately, and noted in the dossier with a new date.
Entirely fictional example: application, roles, test data and sources are invented. It does not evidence any service actually performed and contains neither a score nor a seal.
WORKFLOW

From initial contact
to a dated report.

  1. 01 / QUESTION

    Clarify purpose and scope.

    At the initial contact, describe the task or question in your own words. We clarify the purpose and scope; identity or bank documents are not requested here.

  2. 02 / SCOPE

    Agree the subject.

    We agree which review questions are relevant, which sources are available and the purpose supporting the review. For technical reviews, we also expressly agree the scope, authorisation and suitable review access.

  3. 03 / REVIEW

    Cross-check sources.

    Statements are recorded by source, compared and documented with a date.

  4. 04 / REPORT

    Deliver the dossier.

    You receive the dated report with findings, inconsistencies, missing evidence and proposed next steps. For technical reviews, the affected location, risk, priority and remediation are named; a follow-up check of specific corrected items is optional and agreed separately.

LIMITS AND SOURCE STATUS

Validity and limits.

  • Statements relate to the documented source information and the stated date. Circumstances may change later.
  • The report does not guarantee approval. There is no guarantee of authenticity, security or delivery, and no legal, tax or investment advice.
  • Phantom Check is a review with an agreed scope, rather than a ready-made, automated review platform.
  • Reviews involving personal data require a legitimate purpose. KYC is an optional component.
  • Banks remain responsible for their own bank-specific reviews.
  • Technology and system analyses and targeted security tests cover only items expressly authorised for review, within the agreed scope. This is not a certification and not guaranteed full coverage; no security assurance is given.

For commodity enquiries, a more detailed review can be scoped separately through this optional service. Go to commodities

HAVE A QUESTION TO EXPLORE?

Describe
the task.

Use the form to explain what needs to be clarified and why. Please do not send identity or bank documents or access credentials through it; we will then agree a suitable way to exchange documents.

Describe your question