FACE Recognization with geocoding

Pricing details, per-API transaction costs, and exact monthly estimates for Azure AI Face (Face API) aren't provided in the context, so only structural and functional aspects can be described.

For this scenario (employee attendance using face recognition with 100–500 employees, 2 punches/day, using Detection, Identification, and optionally Liveness), the following applies based on the service behavior in the context:

1. API calls involved per punch

A typical “punch” that uses face recognition generally requires at least:

• One Facial detection call: to answer “Are there one or more human faces in this image?” and to get bounding boxes for faces.
• One Facial identification call: to answer “Can this detected face be matched to any enrolled face in a database?” (one-to-many matching against the employee group).

So, per punch, at least two API operations are involved:

• 1 × Detect
• 1 × Identify

If Facial liveness detection is added, an additional Detect Liveness operation is used to determine whether the face is real and present.

2. Functional differences between Detection, Identification, and Verification

From the context:

• Facial detection
  • Finds human faces in an image and returns bounding boxes.
  • Can optionally return facial attributes (pose, landmarks, etc.).
  • Models are incapable of verifying or identifying individuals and do not create facial templates.
  • All other Face API functions depend on detection first.
  • Reference: Use cases for Azure AI Face service
• Facial identification
  • “One-to-many” matching.
  • Answers: “Can this detected face be matched to any enrolled face in a database?”
  • Returns candidate matches based on similarity between the probe image template and enrolled templates.
  • Used for scenarios like matching an employee’s face against a group of enrolled employees.
• Facial verification
  • “One-to-one” matching.
  • Answers: “Are these two images of the same person?”
  • Compares a probe image template to a single enrolled template.
  • Typical use: comparing a selfie to a stored ID photo.

Functionally, an attendance system with a shared employee gallery normally uses Detection + Identification rather than Verification, unless each punch is explicitly comparing against a single known reference image.

3. Facial liveness detection impact

From the context:

• Facial liveness detection
  • Determines the authenticity of a face and returns a liveness classification (live vs spoof).
  • Models are incapable of verifying or identifying individuals, but may find, extract, or create facial templates to ensure the same person is present during the liveness test.
  • Can be used standalone (e.g., as a CAPTCHA alternative) or combined with verification/identification to improve security.

Adding liveness means:

• One additional liveness operation per punch (if required for every punch).
• Higher overall transaction count compared to using only Detection + Identification.

4. Limited access and eligibility

The Face service is a Limited Access service:

• Access is limited based on eligibility and usage criteria.
• Only available to Microsoft managed customers and partners.
• Use the Face Recognition intake form to apply for access.
• Certain capabilities (for example, some recognition features) are limited to approved use cases.

Note: Facial detection, facial attributes, and facial redaction use cases do not require registration, but identification/verification scenarios do fall under the Limited Access policy.

5. Storage and training

From the context:

• Facial detection models do not find, extract, or create facial templates.
• Facial liveness detection models may find, extract, or create facial templates, but only to ensure the same person is present during the liveness test.

The context does not provide explicit billing details for:

• Storage of enrolled faces/person groups.
• Training or management of those groups.

Therefore, no cost statement can be made about storage/training from the provided information.

6. Cost estimation and optimization

The context does not include any numeric pricing or per-transaction cost, so no concrete monthly cost estimate can be calculated here.

However, cost optimization for this pattern, based on the functional behavior in the context, generally involves:

• Minimizing unnecessary calls:
  • Ensure each punch performs exactly one Detect and one Identify (and one Liveness call only if required).
  • Avoid repeated detection/identification if the same frame is processed multiple times.
• Using the appropriate function:
  • Use Identification for one-to-many employee matching.
  • Use Verification only when explicitly comparing against a single known reference image.
• Using liveness selectively:
  • Apply liveness detection where risk is higher (for example, first punch of the day, or high-value operations) rather than on every single punch, if business requirements allow.

For precise pricing, per-API transaction costs, and a numeric monthly estimate, the Azure pricing calculator and the Face service pricing page must be consulted directly, which are not included in the context.

References:

• Use cases for Azure AI Face service
• Azure Face API
• Use Face Check with Microsoft Entra Verified ID and unlocking high assurance verifications at scale
• FAQs about AI capabilities in Dynamics 365