Security Policy

Our security approach

Valtoria applies layered controls intended to reduce unauthorized access, fraud, data loss, and operational error. Controls are selected based on risk and may include access restrictions, secure development, audit records, session protection, transaction review, reconciliation, backups, monitoring, and incident procedures.

No system can promise absolute security. This is not a certification or a claim that a named standard has been independently audited.

Account protection

• Passwords are handled with one-way password hashing.
• Authenticated actions use session and request-integrity controls.
• Administrative functions are limited by role and permission.
• Sensitive operations and status changes should produce traceable records.
• Suspicious access may be limited, reviewed, or blocked.

If email one-time codes or another control is unavailable or not correctly configured, it should remain disabled rather than be represented as active.

Manual operation controls

Funding, transfer, credit, and repayment requests may enter a manual operations queue. Authorized personnel move requests through pending, processing, completed, or failed states. Completion must correspond to an operational decision and appropriate ledger entry; changing a label alone is not sufficient.

Approval thresholds, supporting evidence, idempotency, reconciliation, and immutable corrections should match the risk. Manual processing is not permission to bypass controls.

Payment-card data

Routine records should contain only permitted metadata such as network, last four digits, cardholder label, justified expiry information, and partner or operation reference. Displayed card numbers must be masked except for a documented business need.

If a partner operation requires complete card information, collection and transmission must use a separately reviewed, access-controlled, auditable, PCI DSS-aligned channel with defined retention and deletion rules. Manual handling is not an exception.

Data and infrastructure safeguards

Controls should include encrypted transport, secure configuration, patch management, least privilege, secret separation, protected backups, sensitive-field redaction, and recovery testing. Production credentials and data must remain separate from development and test environments.

We do not describe a control as enabled, certified, or externally monitored unless it is implemented and verified.

What you should do

• Use a unique password and secure your email and devices.
• Use a trusted bookmark or type the site address before signing in.
• Never share passwords or one-time codes, including with support.
• Review beneficiary, amount, fee, and status for each request.
• Report unfamiliar activity immediately and preserve references.

Incident response

Suspected incidents are triaged, contained, investigated, documented, and remediated based on severity. We may restrict an account or operation during investigation. Affected users, partners, authorities, or regulators will be notified when applicable law or an agreement requires it.

Responsible vulnerability reporting

Report a clear description, affected feature, reproduction steps, and impact. Avoid accessing other users’ data, changing balances, disrupting service, social engineering, high-volume testing, or collecting unnecessary data.

This policy does not itself authorize testing. Wait for written scope and authorization before intrusive tests.

Scope, partners, and review

Partners and providers are responsible for security in their own systems and contractual scope. Compatibility with a partner card program does not establish network endorsement, certification, or a direct network relationship.

We review this policy as the service, threats, and obligations evolve. Operational claims should be added only after controls are implemented.