Weekly Team Updates

VSP Dashboard Logic

Fixing VSP dashboard logic.
Requires understanding and updating DVD model.
Takes time (1.5 days).
Involves Gautam and Rafi due to PSP table complexity.
Requires understanding from engineering and PM perspectives.

ISOC Project Documentation

Getting documentation and action items from the data team regarding the ISOC project.
Need to understand the ISOC service flow and database.
Used by revenue operations for billing.
Customers are charged when they use the ISOAP service.
Testing to export ISOOPS data in different formats.
Creating dummy data to illustrate data transformation.
Presenting simulation to revenue operation, engineering, and product teams.

Automate Review Process in Angkor Project

Automating the review process in the Angkor project.
Currently using consensus with manual review by the review team.
Agents separated into process and third team.
Reduced number of review members are allocated to the NZTOR team.
Upstream wants better allocation because they will have many things to be labelled.
Goal is to help them.

FAIR Pipeline Updates for Doc Verification

Updating the FAIR pipeline for document verification.
Changing one of the ontologies for the project.
Need to refactor everything affected by the change in ontology (mainly the parsing script of labels).
Incorporating the change for forcing the Angkor project creation to be manual from manual QA to consensus workflow, requiring it to be on a workflow style.
Previously, creating an Angkor project would result in an orange designation, indicating a manual QA type, but this will be deprecated.
In the future, all projects will be purple, indicating a workflow.
Making the change to allow the pipeline to work for other card types in addition to MyCAD.
The pipeline should now work for any card types that may come.
End-to-end testing for both MyCAD and other Malaysian ID cards (e.g., MyCenterra).
Updated the parsing script so that it works with the changes.
Creating a report based on the CSV file that the parsing script pulls data from.
Post-processing will create FAR/FRR values.
The output of the processing process will look like, and it is now ready for when YTO wants the report, but is currently in a waiting game.

Malay ID Digital Number Splicing Fraud Detection

Working on Malay ID digital number splicing.
Trying to catch fraud where the ID number or name is printed and superimposed onto the card.
This could pass the spoof liveness check but fail the forgery check.
Synthetically creating data to capture the look and feel of these types of images.
Created approximately 15,000 images for training and trained the model.
The result is a model with a test set composed of around 4,600 images and 22 fraud images.
Trying to catch the 22 fraud images while not rejecting any of the 4,600 legit images.
Developed a method that can catch about 14 out of the 22 fraud images while not false rejecting any of the legit cards.
This is ready for MyCAD.
Need to test this model on more MyTenterra cards.
The model was not trained on MyPR, so it will not work on MyPR at this iteration, but plan to add that in the future.
Currently working on using the same approach but synthetically create for the name, part in the Malay ID to catch the, the name the name name overlay, for an example, like now trying to catch this part, the name.
Scraping and trying to create this synthetic dataset, which hopefully will result in a model that will actually catch this type of images.

Syncing with Other Teams and Prioritization

Syncing with other teams on priorities.
Teams had a QBR (Quarterly Business Review).
Looking at metrics and what's being done.
Most things have been resolved.
Trying to find time to relook at the fraud model.
Fraud model 1.8.2 for BRIs has been delayed, but launching a final version soon.
Fraud model 1.7.6 is being cracked for BIPA GIST.
Fraud models are being escalated.
Focusing completely on fraud models once data is available.

AWS FTR

Working on AWS FTR (Well-Architected Framework Review).
Documentation and remediation of required findings completed.
Submitted required documents to AWS.
Good on this front for now.
They want to know about the establishment of disaster recovery testing and processes.
Will work with engineering in FLOPS regarding that and complete that.
All follow-up questions for RTORPO and CIF reports have been answered. We are good on that front.

Features for Fraud Detection Model

Sorting out the features for the fraud detection model.
Basic understanding of the data coming from the mobile SDK, which has been documented.
Roughly 26 top-level keys with inner keys within them.
Trying to get the feature plan, like what kind of features will be useful for training a model and how to generate those features.
For gyroscope accelerometer, the current value of the x is not as meaningful as the mean or delta.
For proximity sensors and other sensors, only some values are more meaningful and can be used as is.
Trying to go over each of these signals, like sort of they are sort of feature groups in our case.
Get going it over each and every feature group and trying to, like, mark which features we can extract.
For gyroscope accelerometer magnetic field, can capture features like the mean, all the aggregation features.
Also, at the same time, converting those to numerical values from everything is in a string, we are typecasting it to required integer or float as required.
Generating some features, like in the clock feature, we get current time and network time and but we are trying to find if there's a drift, what is the difference between the current time and the network time so that it can be used as a feature.
Trying to aggregate CPU details, how many CPUs are there and what is the mean performance indicators instead of going over each CPU.
Capturing how many system features exist, for example, in this system features, we're just trying to capture how many system features exist.
In this device, it's a hundred and one.
Goal is to have features ready before we have the data because this is the next phase we have to do any design.
Trying to train dummy models just for the sake of doing the training process.
Feature generation will also be different; might need to do some feature engineering, even for the numerical ones.

Suggestions on Feature Selection

Focus on under five features even in the first model; it will likely be a rule.
Can create many features to get comfortable with data but be aware that many may be thrown away once real data comes in.
Just curiosity might lead to stumbling upon something useful.
Trying to understand how Sandeep generates the features and using ChatGPT to explain what this means.
Trying to ask g p ChatGPT, like, what is suspicious, what is not but it's it's unclear whether it's not work it's working or not.
ChatGPT said, it's be hallucinating quite a bit.
Capturing all the things from mostly this API.

Supporting Randy for Data Collection

Supporting Randy for the collection data for the project color caption.
Data collection by agents is ongoing today.
After the meeting, will meet with Randy to review data collected today.
Supporting BD for fraud scanning for high bank; finished credit report.

Fraud Scanning for High Bank

BD requested fraud scanning from high bank. Try our liveness from the SSP.
Data: 79k data points. It is a table result from our model.
Acceptance rate: 79%.
Rejection rate: 5%.
Rejected by IKA: 15%.
Sampling for labeling: 0.9% (100) and below 0.9% (18%).
Found two indications of injection attack (border, black border in the frame).
Cases rejected by liveness.
Rejection from under exposure, blurred image, press occlusion, unnatural color, and upper exposure.
The BD, they want to see I think, they want to see rejection from these mesh shades
The BD will have a meeting with the product team to create a presentation for HIBAN on our models' performance.

Separating Label Watermark and Uploaded

Discussed with Jeff about separating label watermark and uploaded because we want to focus other label for the specific IKEA image quality.
Yesterday, the watermark was in the main label; today, we create new main labels for watermark and upload.
For March and April, should we go back to the old version FAR, FRR?
In March, FAR went from 23% to 3% due to a definition change, not a model improvement.
Request to see if we can use the same definition as in February and March.
Data for March is still available and can be calculated in a way that's consistent with February, the old definition.

Issues With Watermark Labeling and FAR/FRR

The problem is that January, February, and March took the label from the watermark.
If the watermark label is EA or injection attack, they want to move it to others to reduce the scoring rate.
Need to introduce another category.
This looks weird as we can't compare month to month anymore.
May need to rebenchmark the path, at least for March.
March and April, we benchmark and calculate the same way.
Also, introduce the new category to them - introduce other watermarks and socialize why we're doing this.
It will take a couple of months for people to switch over, then everyone will be on the same page.
Use the same ontology, but for the calculation, we will need to modify the script.
The watermark distribution adds another column; 8% is watermark, and the other 4% is the common injection attack.
Just don't change the ontology; change the calculation script.
Include the others' watermark or anywhere you put the watermark.
If we have the resource to reannotate the IA labels, then we can put that one.
If hard to reach, we can have a discussion.
Need to socialize this with people because many more people are looking at it now.

Plural Assessment and Production Escalation

Several tasks this week include plural assessment, production escalation from Ningraya, short playbook writing, and active flight test.

Blur Assessment

Two main goals: adjusting model thresholds and handling background blur.
Adjusting brewer model thresholds and rebenchmark with new data for more tolerance.
Background blur is not captured by current models (ROI is on facial area only).
Using synthetic blur assessment model can capture blurred backgrounds without retraining by changing the ROI.

IQA and Fraud Rejection

Shouldn't reject fraud in IQA because IQA doesn't go into FAR/FRR analysis.
Consider annotating blur as a blur annotation project to collect background blur data along with another blur.
New ontology for more fine-grained triaged groups.
Blur data collected from January 1 to April 13.
Data source is annotation labelled blur, noisy, live slightly blurred, and rejected by assessment models; totals to about 17,000.
Data in the rejected assessment model are often spoofed either IA or PA due to poor data quality.

Production Escalation

Escalations from banks, Abbott, Samburnak; mostly uploaded data/irregular shape/metadata.
Some live images are manipulated due to focus change.
Suggested to make handling a playbook for this.

Playbook for Handling Escalation

Playbook is useful for handling timed escalation cases.
People addressing home cases. When presentation text or it's not even script type, then there are some rules.
Can put this on chat g p t as a custom g p t and share this one with our new TPM, Aman who's handling this kind of escalation.

Active Flight Test

Handling the active task; need to learn deeper the TC codes.
Currently adding new algorithm and developing for this one.
Testing the image correlation score on other active images in making a new final scoring for the active lightness.
Several ways to put image population score in the active license endpoint.
Option: Either the engineering pipelines or put the image manipulation model inside the active lifeless endpoint
If doing that, like in the passive lifeless, actually, it's gonna be really an efficient way to maintain and also might be painful to maintain.
Discussed with Keshav if, from level endpoint, can access the image manipulation endpoint to get response from the proof points.

Concerns About Active Liveness Implementation

Have you checked how much we can actually catch with existing approach?
Need to test both approaches.
Run like have you gone through, like, historical data to see how much fraud we can actually catch.
If too much work, deprioritize this right now or unless you can tell us you will catch x thousand fraud attempts.

Liveness implementation

Can be deprioritized in a sense, right like if there's not much fraud? But can be implemented of a ton of fraud going through; higher priority if it's necessary.
New SDK would take care of that, updated the ZDefend handling.

Color Capture and Metrics

Focusing on color capture, collections, and calculations.
The issue is outdoor capture, which is correlated with sun brightness.
After adding algorithms to the Mediemo SDK and data collection by Irfan.
The Lux value from the sensors is reliable and distinct on indoor, which prevents collecting on outdoor.
In the evening, it's zero to eleven, and the average around 38 and I think the maximum is around 80 or 100.
Outdoor values collected under sunlight will be around five k.
If they don't have it, we should go to exposure values: 0.03 on the average, but the outdoor is around 1.14.
It's an exposure from the frame.
I'm hoping it can be used for a web SDK.

Issues With Outdoor Data and Training

Outdoors are supposed not to be a problem because I don't think they are gonna. Put it more sensitive, less aggressive, but is still good compared to the the one from the engineering and other engineers.
BW is trying to detect the dark spotlight, but no one recommended this one. It's implemented.

Model Challenges and Data Collection

The more I look into it, the detail is there is a lot of problem I need to solve.
When we give non colored flash, the model will still try to predict certain color as random.
Trying to add this capability on the model to actually protect this kind of issue.
Either adding on the current model, and if it doesn't work, add another small model.

Detailed Analysis and Model Iteration

Continue analysis on the FRR of certain range of lux value, more detailed one, and also the accuracy in each color.
FRR on the color prediction of certain phone type.
Training models to add the capability to fix it. Collect data that was collected by Irfan and the data team on the ops team.
- Trying to add the capability of non colored flags and try to reject it if we detect it as a non colored, and try to improve the model color prediction accuracy.

Color Capture Discussions

The UX and product team kind of pushed me over. It seems like I'm the one actually working on this, and they are just trying to push me everywhere.
Getting asked if have any test on the web SDK, which don't have even create. Try to, involve you in the loop in response.
In the future next week for this one, just want to add new data so I don't need to debate without any data backing it up. Make sure what is been ask is not weird.
Trying to add black colors the future.