Every change approved, every action logged

Every template edit moves through a configurable approval chain: draft, review, and approval before going live. The template creator submits changes, and the designated approver receives a notification. Approvers can review the changes, including a side-by-side diff of the before and after state, and approve or reject. Multiple approval levels are supported: first approval, second approval, DLT portal approval, then live. Every approval step creates an audit trail entry with timestamp, approver identity, and decision. No template reaches any channel without sign-off.

Yes. An ad-hoc campaign targeting any audience will not send until an approver approves. Approvers receive email notifications with campaign details and estimated cost. Approval can be completed via email link, with optional IP-based access restrictions, or through the application. This prevents bulk sends without oversight. The audit trail records who approved the campaign, when, and what audience and template were used.

Fyno integrates with Microsoft Azure Active Directory and Google Workspace. Domain-based authentication enforces SSO login for all users from a specific email domain. Fyno does not maintain passwords or user credentials. Access is controlled entirely through your existing identity provider. When an employee leaves and their identity provider access is revoked, their Fyno access is automatically revoked. No separate deprovisioning needed.

The audit log captures every action on the platform: template edits, routing modifications, campaign executions, consent policy updates, approval decisions, and configuration changes. Each entry records who performed the action, what changed, when, and the before/after state. Logs are forwarded to callback endpoints for integration with external audit systems including SIEM and compliance dashboards. The trail is designed to satisfy RBI IT audit requirements where auditors trace any communication event back to its configuration, approval, and execution chain.

Every template and configuration change creates a new version. The version history captures all edits with diff-level detail: what changed, who changed it, and when. Any prior version can be viewed side-by-side with the current live version. Rollback is a single action: if a live template causes delivery failures or a compliance issue is identified, teams revert to a previous approved version without engineering involvement. Test versions can be created and tested before going live. The version history is immutable and cannot be edited or deleted.

Yes. Routing configuration changes, provider credential updates, consent policy modifications, and short link domain whitelisting all require approval through the governance workflow. Template deletions, including removal of unused templates per TRAI guidelines, are tracked through the approval flow. The same maker-checker logic that governs templates extends to all system configuration, ensuring that no single individual can make changes that affect live communication flows without oversight.

Fyno provides three things RBI auditors look for. First, an immutable audit trail that traces every communication event back to its template, approval chain, and execution details. Second, version control with tamper-evident change records that show the complete history of every template and configuration. Third, maker-checker approvals that demonstrate segregation of duties: the person who creates a template is not the person who approves it. All records are timestamped, retained according to your data retention policy, and exportable for audit review.

Fyno measures every message against the SLA category it belongs to: OTPs at 5 seconds, transactional at 15 seconds, service messages at 30 seconds, marketing within its declared window. Each delivery is timestamped at vendor handoff and at final delivery callback. The platform compares actual delivery time against the SLA threshold per category, per vendor, per channel. A monthly report surfaces every breach with the message ID, vendor, channel, expected SLA, and actual delivery time attached. Banks use this report in two ways. First, to enforce contractual SLA penalties with their CPaaS vendors using objective platform-side evidence. Second, to make data-backed routing decisions, shifting traffic to better-performing vendors before customers feel the impact. The SLA report runs automatically and is included in the audit trail for regulatory review.

Suppression list is a bank-owned blocklist that Fyno checks before every send across every channel. Banks upload mobile numbers or email addresses they want to suppress, with an optional reason tag (fraud complaint, customer request, account closure, regulator instruction). Every campaign send, every triggered alert, and every transactional message is checked against the suppression list at the routing layer in real time, before reaching any vendor. Blocked messages are logged with the recipient, the reason code, and the timestamp, and surface in the audit trail. This protects against three scenarios. First, mistyped numbers that risk sending bank data to the wrong person. Second, customers who lodged a complaint but whose preferences may not yet have propagated to every source system. Third, accounts closed in CBS but still active in marketing databases.