ACCEPTABLE USE AND API USAGE TERMS

Effective Date: 2026/09/01
Last Updated: 2026/08/28
Version: 1.002

These terms govern acceptable use of the FICA sure platform and APIs and supplement the FICA sure Terms and Conditions.

1. Permitted purposes

FICA sure may be used for legitimate activities relating to:

FICA compliance;

KYC;

customer due diligence;

AML;

counter-terrorist-financing controls;

sanctions compliance;

PEP screening;

identity verification;

fraud prevention;

business verification;

beneficial-ownership verification; and

other lawful compliance purposes.

2. Lawful authority

A Client must have a lawful basis for screening an individual or processing their Personal Information.

FICA sure may not be used merely to search people out of curiosity.

3. Data minimisation

Only information reasonably required for the verification should be submitted.

Unrelated sensitive information should not be provided.

4. API authentication

Authenticated API requests must use valid FICA sure credentials.

Clients are responsible for protecting API keys and other credentials.

5. Server-side credentials

API credentials should ordinarily be stored server-side.

They must not be exposed in public JavaScript, public repositories, screenshots, client-facing logs or other publicly accessible locations.

6. Test and live credentials

Test and live environments are separate where provided.

Test keys must not be treated as production keys.

Synthetic or sandbox results must not be represented as live verification results.

7. Customer identifiers

Clients should retain both their own external customer/reference identifier and the FICA sure case identifier returned for the verification.

8. Application types

Clients should use the appropriate application type for the Verification Subject.

Where FICA sure provides a machine-readable application schema, Clients should retrieve it and follow the current field and document requirements.

9. Input fields

Where a field is identified as:

required, it should be provided;

optional, it may be provided where appropriate; or

not applicable, it should ordinarily not be submitted for that application type.

10. File uploads

Clients must use the document names and multipart conventions published in the FICA sure API documentation.

Supported document formats may include JPEG, PNG, WebP and PDF.

Unsupported files may be rejected.

Where multiple files are permitted for the same document category, the published multiple-upload convention must be used.

For example, where documented:

proof_of_address[]

may be used for multiple proof-of-address documents.

Clients must confirm from the API response that all intended documents were actually received.

11. File quality

Documents should be readable, complete, sufficiently clear, reasonably current where required and relevant to the verification being performed.

12. Authenticity

Successful upload or processing does not guarantee that a document is authentic.

Automated document analysis may identify anomalies but cannot guarantee detection of all manipulated or fraudulent documents.

13. False data

Clients must not knowingly submit false, stolen, fabricated or manipulated identity information into the live environment.

Approved synthetic test data may be used in a designated test environment.

14. PEP screening

A PEP result does not automatically mean rejection.

Clients should investigate the match and conduct appropriate enhanced due diligence or risk assessment.

15. Sanctions screening

Potential sanctions matches should be investigated using available identifiers before material action is taken.

Where the law requires blocking, freezing, reporting or other action, the Client is responsible for satisfying that obligation.

16. Matching

Name matching, fuzzy matching and transliteration can produce false positives.

Clients should use additional identifiers such as date of birth, nationality, ID number or passport information where available.

17. Human review

Human review should be performed where appropriate, particularly where:

a significant PEP match occurs;

a sanctions match occurs;

identity information conflicts;

fraud or manipulation is suspected;

FICA sure returns review_required; or

a material adverse customer decision may result.

18. Automated decisions

Clients must not blindly rely on automated FICA sure results where the law or circumstances require meaningful human consideration.

19. Monitoring

Where ongoing monitoring is provided, Clients are responsible for deciding whom to monitor, why monitoring is lawful, how alerts should be investigated and when monitoring should cease.

20. Rate limits

Clients must observe published API rate limits.

Attempts to deliberately bypass limits or abuse infrastructure may result in restriction or suspension.

21. System abuse

Clients may not perform denial-of-service attacks, credential stuffing, unauthorised penetration testing, vulnerability exploitation, scraping outside documented interfaces, authentication bypasses or malicious file uploads.

22. Reverse engineering

Clients may not unlawfully reverse-engineer, reproduce or attempt to derive proprietary FICA sure technology.

23. Data harvesting

FICA sure may not be used to create mass databases of Personal Information unrelated to a legitimate compliance requirement.

24. Unauthorised screening

Clients may not use FICA sure to unlawfully investigate neighbours, celebrities, political opponents, employees, family members or other persons without a legitimate and lawful purpose.

25. Discrimination

PEP status, nationality, country of birth or another screening characteristic must not automatically be treated as evidence of criminality.

FICA sure must not be used for unlawful discrimination.

26. Resale

Clients may not resell, sublicense or white-label FICA sure without written authorisation.

27. Report sharing

Verification reports may be shared where reasonably necessary for legitimate compliance purposes.

Reports containing Personal Information must not be publicly published.

28. Result storage

Clients must appropriately secure stored API results and downloaded reports.

Access should be limited to authorised persons.

29. Client retention

Clients remain responsible for determining their own legal and regulatory retention obligations.

30. Interpretation of API results

Statuses such as CLEAR, MATCHED, PEP, REVIEW_REQUIRED, NEEDS_INFORMATION or similar values must be interpreted according to current FICA sure documentation.

CLEAR is not a guarantee of no risk.

PEP does not automatically mean prohibition.

REVIEW_REQUIRED does not automatically mean rejection.

31. Error handling

Integrations should safely handle authentication errors, permission errors, validation errors, duplicate identifiers, insufficient credits, missing resources, server errors and temporary service failures.

32. Retries

Automated integrations must not create uncontrolled retry loops.

Reasonable retry delays and back-off should be used where appropriate.

33. Callbacks and webhooks

Where callbacks are supported:

production callback URLs should use HTTPS;

endpoints must be appropriately secured;

signatures should be verified where supplied;

Personal Information must not be exposed through unsecured logs; and

callback endpoints should not be unnecessarily publicised.

34. Logging

Clients should maintain appropriate security and audit logs.

Logs should not unnecessarily contain API keys, passwords or full sensitive identity information.

35. API key compromise

A compromised key must be revoked or rotated promptly.

FICA sure may revoke compromised credentials where reasonably necessary to protect the Service.

36. Passwords

Clients must not submit unrelated customer passwords, online-banking passwords, PINs or similar credentials to FICA sure.

37. Client responsibility

The Client remains responsible for decisions and actions it takes based on FICA sure information.

FICA sure supplies verification and screening information to support those decisions.

38. Investigation of misuse

Where FICA sure reasonably suspects abuse, unlawful activity or a security threat, FICA sure may investigate activity, request information, preserve relevant logs, restrict access, revoke credentials or make legally required reports.

39. Changes to API functionality

FICA sure may add, modify, version or deprecate API endpoints and functionality.

Where an incompatible change is introduced to a stable API contract, reasonable versioning or migration measures should be used where practical.

40. Changes to these Usage Terms

These Usage Terms may be updated to reflect changes in legislation, regulation, API functionality, security requirements, Service Providers or operational requirements.

41. Enquiries

FICA sure
Website: ficasure.com
General enquiries: enquiries@ficasure.com
Privacy enquiries: enquiries@ficasure.com
Security reports: help@ficasure.com