Service operation and support

Use the support and incident channels named in the applicable Finsaku agreement. This page explains the information to provide and the checks a customer can perform; it does not define a contractual response time or service level.

Report a service problem

Provide enough information to identify the affected service without copying credentials or unnecessary customer data:

• tenant and environment;
• affected page, workflow, integration, or MCP client;
• time of the event, including time zone;
• user-facing error and relevant record reference;
• expected result and actual result;
• whether one user, one workflow, or the tenant is affected;
• safe reproduction steps;
• applicable audit or execution-history reference.

Do not send passwords, API keys, access tokens, full provider payloads, or unrestricted customer exports. Use the agreed secure exchange when support needs additional evidence.

Report a suspected security incident

Use the security contact in the agreement when confidentiality, integrity, availability, unauthorised access, or personal data could be affected. Preserve the original timestamps and evidence. Do not repeatedly retry a destructive or externally delivered action while its outcome is uncertain.

The customer remains responsible for its internal incident classification, regulatory assessment, notifications, and communications. Finserio provides the assistance and notices defined by the applicable service and data-processing terms.

During an external-provider outage

An integration failure does not necessarily reverse the Finsaku operation that triggered it. For example, an application change can succeed while its email, SMS, document, or webhook action fails.

1. Check the affected application, loan, payment, or configuration state.
2. Review Administration → Execution History for the external action.
3. Check the provider reference or provider portal when authorised.
4. Establish whether the provider received the request before retrying it.
5. Record any manual workaround so it can be reconciled later.

See Audit trail and Event actions.

Verify restored service

After a service or provider is restored, test the smallest representative path before resuming batch work:

1. confirm sign-in and intended access;
2. open an existing person, application, or loan without changing it;
3. verify the affected workflow with a controlled case;
4. reconcile saved state, history, external-provider outcome, and any financial effect;
5. check that retries did not create duplicate messages, documents, payments, or downstream actions;
6. record the verification result and unresolved exceptions.

Backup and recovery evidence

The standard hosted deployment includes database and file-storage backup mechanisms. Backup scope, retention, isolation, restoration process, recovery objectives, test results, and customer notification are deployment-level matters. Obtain their current values from the contracted service documentation rather than treating a help-page example as a commitment.

Customers should define which lending workflows must be reconciled after restoration and keep the contacts, decision rights, and manual procedures needed to continue or safely pause work.