Correction policy / Validated intake
NeobankDB welcomes precise corrections to classifications, entities, markets, fees, limits, protection arrangements, regulatory records, payment infrastructure, comparisons and route conclusions. A submission begins review; it does not overwrite a public fact, guarantee an answer or let a provider replace evidence with a preferred description.
Every candidate needs an exact page and market, the claim to review, a proposed correction, public source URLs and anobserved date. Validated API intake stores a non-public candidate only when durable storage confirms receipt. Email remains the explicit fallback when that service is unavailable.
Security boundary
Do not send passwords, one-time codes, recovery phrases, identity documents, account or card numbers, balances, private statements, transaction records, support-chat exports or files containing customer information. NeobankDB does not need credentials or access to verify a public claim. The intake accepts links, not document uploads.
This channel is not provider support, a payment trace, fraud reporting, an emergency line, a regulator complaint or legal notice. Contact the institution controlling the account or transaction and the appropriate authority for those matters. A correction receipt confirms editorial intake only.
Validated candidate intake
Required fields are marked . A stored submission remains unverified and has no publication effect until review is complete.
The configured API returns a receipt only after durable storage. Static builds and unavailable backends fail closed.
Use corrections@neobankdb.com email fallbackCorrection scope
Use the examples to choose the editorial path without disclosing private information.
In scope
The named legal entity changed; a provider left a market; a fee schedule lists a different amount; a regulator register shows a current permission; a protection limit or eligibility boundary changed; a payment rail record names a different operator; or a route source now supports a different directional conclusion.
In scope
A claim is accurate in one country but written globally; a bank and non-bank product are merged; a partner institution is attributed to the whole brand; a protection statement omits pass-through conditions; or a comparison obscures an important evidence boundary.
Different channel
A card was declined, an account is restricted, a transfer is pending, identity review is unresolved, cash is missing, support has not replied or a personal fee differs from a public schedule. Those require authenticated provider support and may require an appropriate complaint or dispute path.
Not evidence
“Rank us first,” “remove criticism,” “our product is best,” “everyone supports this rail” or a request with no verifiable source is not a correction. Commercial relationships, popularity, threat of lost advertising and affiliate payout cannot alter the evidence standard or decision.
Review workflow
The public intake and the future private review workspace remain separate systems.
Provide the canonical page path, market and precise sentence, field, table row or route conclusion to review.
Link one to five public HTTPS sources and record when the evidence was observed.
Validated intake creates a received-pending-review record with no immediate publication effect.
A reviewer checks subject, entity, product, plan, market, value, dates, source authority and conflicting evidence.
The candidate can require more evidence, duplicate an existing item, be accepted, be rejected or remain unresolved.
Only an approved correction updates public copy; prior evidence and dates remain available to the publication audit trail.
Decision states
A submitted record does not disappear merely because the proposed wording was not accepted.
Provider and authority responses
A provider representative, regulator or scheme operator should identify the exact legal entity, product, plan, market and source they are addressing. A corporate email can help the editorial team understand provenance, but the proposed statement still needs current evidence and the same conflict analysis applied to every other submission.
Relevant context and primary evidence receive review. A response can clarify scope, correct an entity or point to a newer official record. It cannot buy removal, suppress a supported limitation or replace a public source with an unverifiable assurance.
The public form is not an embargo channel and makes no confidentiality promise. Do not submit non-public launches, customer files, internal screenshots or documents you are not authorised to share. Contact by email first to ask whether a secure process exists.
A correction can change an underlying evidence record after approval. It does not create a bonus, penalty, ranking preference or assumed high confidence because of the submitter’s role, advertising relationship or speed of response.
Data minimisation
Public evidence and precise scope are useful; customer secrets and account records are not.
Page path, market, claim, proposed correction, public source URLs, source observation date, submitter role, confirmations, receipt ID, review state, decision notes and publication relationship. Contact email is optional and exists only for editorial follow-up.
Passwords, PINs, one-time codes, recovery phrases, card or account numbers, identity documents, balances, private statements, full transaction records and device access are not required for public fact verification.
There is no promised response or publication time, authenticated tracking portal, guaranteed acceptance or confidential whistleblower system on this page. The receipt ID is an audit reference, not a support ticket service-level agreement.
Before submitting
The evidence guide explains candidate, approved, stale, conflicting, unavailable and confidence states. The source directory exposes approved public citations. The changes ledger records page publication, not provider events. Use all three to identify the exact gap before opening a correction candidate.