An Azure service that provides access to OpenAI’s GPT-3 models with enterprise capabilities.
Hello Suchang Ko,
Greetings! Thanks for raising this question in the Q&A forum.
Error 715-123420 ("Our system has detected this request as unusual activity for your account") is not a quota, permission or configuration problem. It comes from Azure's automated risk and fraud protection checks, which run when a model deployment is validated, before anything is provisioned. That matches what you see: the same error on every model (gpt-6-luna, gpt-6.1-sol, gpt-4.1-mini), quota showing 0 of 250 used, a healthy resource and an active subscription. When this check flags a subscription, the block applies to all deployments on it, and it cannot be cleared from the portal, by changing regions, or by redeploying. Only the Microsoft team that owns the risk review can lift it. This is the same pattern other users have reported with this code, so your analysis is correct. I cannot see your subscription or lift the block from this forum, so the goal is to get your case in front of the right team.
Here is what I suggest:
Stop retrying and do not delete or recreate resources. Repeated failed deployments, or deleting and recreating the resource, can make the activity pattern look worse to the automated system. Keep the current resource as it is.
Get your support case routed to the right queue. Your case 2610150060002155 has no engineer assigned, and your earlier case was closed as a quota request, which is likely why it went to the wrong team. Open a new support request (or update the existing one) with these exact settings: Issue type Technical, Service Azure OpenAI in Foundry Models (or Azure AI Foundry), and a problem type about model deployment failures. Do not choose a quota request type.
Use wording that points at the risk review. In the description, write that deployments fail with 715-123420, that you suspect an automated fraud or risk protection (RTFP) hold on the subscription, and that you ask for it to be reviewed and lifted. Include the subscription ID, the resource name and region (koreacentral, GlobalStandard), the date it started (2026-10-11), the latest failure time (2026-10-26 02:41 UTC), the correlation IDs from the failed deployments, the models you tried, and your existing case number 2610150060002155.
Explain your use case briefly. Add one or two lines that this is a personal dev and test subscription for a small tool that classifies your own Slack mentions, with low volume. Reviewers use this to confirm that the block was applied in error.
Check that the subscription itself is in good standing. In the portal, look at Cost Management + Billing for any payment issue, spending limit or billing hold, and at Azure Policy for any Deny assignment on Foundry or Cognitive Services deployments. These are unlikely to be the cause given the error, but ruling them out saves time in the case.
Escalate the stalled case. In the portal, open the support request and use the option to add a note asking for escalation, because 12 days without an engineer is outside normal response times. If your subscription has a support plan, you can also set the severity accordingly. If you have no paid support plan, you can still open requests for billing and subscription issues at no cost, and you can ask in the case for the issue to be handled as a subscription management or fraud review request. You can also ask a Microsoft moderator in this thread to route it, but account level actions still go through support.
Use a workaround while you wait, if you can. If you have another subscription (for example a new pay-as-you-go one in good standing), you can test deployments there. Note that creating many new subscriptions to get around the block can itself trigger more flags, so use only one and keep the usage normal.
If this answer helps you kindly accept the answer which will help others who have similar questions.
Best Regards,
Jerald Felix.