# razorpay-ifsc-schemas
json-schema(s) of ifsc data
[released](https://github.com/razorpay/ifsc/releases) by
[github.com/razorpay/ifsc](https://github.com/razorpay/ifsc).
Note: The schemas only validate the types and required properties. Later,
enumerations, patterns, and limits can be added to restrict values further.
## Issues
[v2.0.11](https://github.com/razorpay/ifsc/releases/tag/v2.0.11) has some
issues. They can be identified with: `ajv -s <schema> -d <data>`.
### banks.json
- Missing `upi` field in some banks:
Can be fixed by:
- marking `upi` field _not_required_ (not recommended as next solution works
better)
- marking `upi` field _nullable_ and ensuring that `null` will be used for
banks with missing `upi` value (similar to other missing properties)
- Extraneous `imps` field in RBIN:
Can be fixed by
- removing `imps` field
### IFSC.json
- IFSC codes are represented either as a `number`, or as a `string`. Numbers
seem to be used for ifsc codes that can be generated by prefixing bank code
to zero-padded ifsc code. Strings are used for ifsc codes that can't be
generated that way.
Suggestion (trade-off, not a fix):
- The `string|number` hybrid approach seems to be used to have compact json
data. Having it done this way will require the consumers to pre-process it.
This can be eliminated by using string ifsc codes exclusively, as most, if
not all modern web servers support gzip compression. This can also allow
zero-copy deserialization.
### by-bank.tar.gz
- Extraneous `upi` and `imps` fields in some banks:
Can be fixed by:
- removing those fields
- Incorrect value of `SBIN.json/SBIN0005181/CONTACT` (expected: nullable string,
actual: number)
Can be fixed by:
- quoting the contact number
